Importing FreeNAS created pools on other ZFS systems?

[DaPlumber]

@DaPlumber, that Oracle documentation you had referenced, clearly says that ZFS needs either an fdisk partition or a slice (that might take the whole disk) ;) VTOC is now only required for root

@solarisguy: Eh, do you consider an EFI label a partition/slice mechanism? :p The docs talk about it as the "whole disk" approach and if you do a "zpool create" with just the disk devices (cXtYdN) with no "slice", an EFI label is all you'll get. Boot disks are a PITA because they have to be backward compatible to boot loaders. It's still worth it the first time you update Solaris with BE's though. :) It's even more worth it when something borks the upgrade process (cough lightning strike cough) and you have to boot off the previous snapshot. :D That's the way EVERY OS should do it, and probably eventually will, just not necessarily with ZFS as the mechanism. ;)BTW do you grok Amber Road or FISHworks and dtrace disks you scream at for heat maps? ;)

Side bar: I'm guessing that FreeNAS would not respond well to booting a previous version after an upgrade? Maybe if we snapshotted the system DB beforehand, but then how do you move the snapshot back if you can't boot the fsck'ing thing? Mount on another system and try and fix? Ugh. Any ZFS upgrade will kill it too.

@cyberjock: Agree with sticking with "vanilla" for production systems. For Home users the family data IS a production system. It's important to note for anyone reading this that I've been discussing a pool used for transport only, i.e. a pool whose data is not the sole copy and can easily be regenerated (albeit not in a timely manner). :(

 

[DaPlumber]

Just for the record, I found the most compatible and easiest way to create a zpool for sneaker-net transport between different machines and FreeNAS (9.2.1.5-RELEASE)is:

1) Create the zpool with the FreeNAS GUI. A mirrored pair is highly recommended but not required.
2) Detach the zpool with the FreeNAS GUI
3) Leave the FreeNAS partitions, etc intact and create a "vanilla" V28 pool in place of the one FreeNAS created. (On whatever system you like, for me OpenZFS on OS X was convenient.)
4) Copy the data you want to transport onto the new pool however (I've only done files/filesystems, no idea if zvols would work.)
5) Export/detach the zpool.
6) Autoimport the pool under FreeNAS in the GUI.
7) Copy your data to where it's supposed to be.
8) Do not attempt to serve shares or do anything else with the imported transport zpool under FreeNAS.
9) Detach the pool from FreeNAS using the GUI.

No, I'm not going to post a command-by-command list because a) YMMV as far as source systems and FreeNAS version to me, and b) if you don't know how to do any of the above you should not be attempting this! (and may the curse of the dog, cyber be upon you!:p )

If your "source" system doesn't understand GPT and EFI, MBR might work but you're probably going to have a bad time anyway.

I take no responsibility for your sanity or the safety of your data. If any of the above turns your FreeNAS box into a pile of mushrooms I suggest making pizza.

 

[cyberjock]

Yeah.. not the most recommended as zpool create could be done with slices(ada0p1) or gptids. Got to get everything right or things may not end well.

I always create v28 pools by simply making an 8.3.1 boot stick, create the pool, then either upgrade to 9.whatever or go back to the other stick with the appropriate version and do an import.

 

[DaPlumber]

Yeah.. not the most recommended as zpool create could be done with slices(ada0p1) or gptids. Got to get everything right or things may not end well.

I always create v28 pools by simply making an 8.3.1 boot stick, create the pool, then either upgrade to 9.whatever or go back to the other stick with the appropriate version and do an import.

Hmmm. Maybe creating "vanilla" V28 pools for transport etc. should be logged as an enhancement request? Not for primary pool use and definitely behind an "advanced" aka "Big Boy" button. It should be a relatively easy task methinks?

 

[solarisguy]

I had to come up with the above procedure, when it turned out my new hardware would not work with FreeNAS 8.x

[LATE EDIT]: the procedure is now below

 

[DaPlumber]

I had to come up with the above procedure, when it turned out my new hardware would not work with FreeNAS 8.x

How well does 8.X work in a VM? I don't have arbitrary elderly hardware lying about the place either. (Actually I do - ask my other half, just not x86 based.)

 

[solarisguy]

@DaPlumber, I was also thinking about requesting such a feature improvement, but realized that FreeNAS actually tries to use new OpenZFS features, and thought that those who need to transport ZFS disks will manage to accomplish the task. You did ;), I did... On the other hand, one should never underestimate stupidity of new users (they would be creating version 28 pools and at the same time complaining that new features do not work...)

 

[DaPlumber]

@DaPlumber, I was also thinking about requesting such a feature improvement, but realized that FreeNAS actually tries to use new OpenZFS features, and thought that those who need to transport ZFS disks will manage to accomplish the task. I did , you did... On the other hand, one should never underestimate stupidity of new users (they would be creating version 28 pools and at the same time complaining that new features do not work...)

Having been a software tester in a previous life, underestimating user stupidity is impossible. Smarter users are still stupid and are the worst as they tend to trip over the worst land-mines. :D

Methinks creating a new class of "thing", a transport pool would maybe mitigate the issue? Implementing this at the same time as an internal zfs send/recv to copy filesystems in the GUI would be nice...

 

[solarisguy]

I have two more legitimate uses for the process, not only making version 28. They are:

• normalization=formD
• utf8only=on

It is not only that I did not have time to make a nice How-To out of it, but also until now I did not figure out who to find a balance between telling users all they need, and not directing new users to a sure disaster.

 

[solarisguy]

I am doing almost the same for creating Version 28 pools. I've done it maybe a hundred times by now. My steps are little different, and I am finding that FreeNAS is very happy (partly due to extra steps with .system dataset):

• Assuming that it would be a new FreeNAS 9.2.x located on a USB memory device, with only one pool.
• Get one more USB memory device, insert it into the system (so you have two USB devices plugged in at the same time).
• Start FreeNAS (you may need to manually tell BIOS to boot from the right device).
• GUI: ZFS Volume Manager: create a pool on the USB device (do not worry, the USB with the OS would not be available; now automagically you have .system dataset on the USB device).
• GUI: ZFS Volume Manager: create a pool (mirror, stripe or RAID-Z*; make sure that no encryption is selected), keep the window.
• CLI: zpool status (and keep a copy)
• CLI: zpool destroy
• CLI: zpool create (version 28 of zpool, using output of zpool status: the same pool name and gptids).
• GUI: ZFS Volume Manager: detach the pool (do not mark the disks as new, as that would erase them).
• GUI: ZFS Volume Manager: Auto Import Volume
• GUI: reboot (not only to be very safe, but also to clear any mismatch with the pool identifier that might have remained; WARNING: most likely reboot process will require help of Ctrl-Alt-Del after it gets stuck upon stopping all USB devices).
• GUI: migrate .system dataset from the USB device to your pool.
• GUI: detach and destroy data on the pool located on the USB memory device.
• GUI: reboot (while rebooting, remove the second USB memory device).

Actual CLI commands would require arguments, not listed above. Your mileage might vary. Offer void where prohibited by law. Other restrictions may apply. The user is solely responsible for the data loss.