FreeNAS to NAS4Free ZFS Migration Error on 9.2.0.1
Posted: 17 May 2014 05:57
Hello,
I've been going back and forth between FreeNAS and NAS4Free, trying to determine the best fork to use. Everything in this post relates to the 9.2 builds of FreeNAS and NAS4Free
I tried FreeNAS after changing primary storage access to LSI, and happily continued with my build until I realized that FreeNAS is running some goofy ZFS ACL options that cause weird errors in permission handling - for instance, if I change a permission via Samba for the owner of a file/directory, FreeNAS will remove all UNIX permissions for the group owner of that file/directory. This, of course, destroys all trust I have in FreeNAS' basic function of secure and reliable storage.
After confirming that NAS4Free does not respond to permission changes in the same way, I migrated back, only to find that my zpools could not be imported because of the com:delphix:hole_birth feature being applied to the pools by FreeNAS.
A presentation from Delphix mentions something about an "enabled" state for function@hole_birth that is supposed to allow backwards compatibility. But an attempt to run "zpool set function@hole_birth=disabled PoolName" prior to returning to Nas4Free failed to resolve the incompatibility, and I'm now back to copying off all my data and rebuilding the pool from scratch.
At this point, I concude that OpenZFS is undergoing serious shifts in how it is managed. The notion of "per-contributor features" has been added to allow new functionality to be added at a greatly increased rate of development. However, the notion that ZFS is an easily cross-compatible filesystem becomes quaint as developers like Ix Systems rapidly include new features without guidance from OpenZFS.
To put it a different way: when supported ZFS functions become de-coupled from the base FreeBSD revision that Nas4Free and FreeNAS are based on, the idea of compatibility within the same ZFS version, and even versions themselves, goes out the window.
Amusingly, running "zpool get all PoolName" on the current version of FreeNAS leaves the "Version" field blank, and doesn't even pretend that it is doing anything cross-compatible.
I'm writing this post to help others avoid the same learning curve, but also to make a clear point to the home user: Avoid FreeNAS.
I've been going back and forth between FreeNAS and NAS4Free, trying to determine the best fork to use. Everything in this post relates to the 9.2 builds of FreeNAS and NAS4Free
I tried FreeNAS after changing primary storage access to LSI, and happily continued with my build until I realized that FreeNAS is running some goofy ZFS ACL options that cause weird errors in permission handling - for instance, if I change a permission via Samba for the owner of a file/directory, FreeNAS will remove all UNIX permissions for the group owner of that file/directory. This, of course, destroys all trust I have in FreeNAS' basic function of secure and reliable storage.
After confirming that NAS4Free does not respond to permission changes in the same way, I migrated back, only to find that my zpools could not be imported because of the com:delphix:hole_birth feature being applied to the pools by FreeNAS.
A presentation from Delphix mentions something about an "enabled" state for function@hole_birth that is supposed to allow backwards compatibility. But an attempt to run "zpool set function@hole_birth=disabled PoolName" prior to returning to Nas4Free failed to resolve the incompatibility, and I'm now back to copying off all my data and rebuilding the pool from scratch.
At this point, I concude that OpenZFS is undergoing serious shifts in how it is managed. The notion of "per-contributor features" has been added to allow new functionality to be added at a greatly increased rate of development. However, the notion that ZFS is an easily cross-compatible filesystem becomes quaint as developers like Ix Systems rapidly include new features without guidance from OpenZFS.
To put it a different way: when supported ZFS functions become de-coupled from the base FreeBSD revision that Nas4Free and FreeNAS are based on, the idea of compatibility within the same ZFS version, and even versions themselves, goes out the window.
Amusingly, running "zpool get all PoolName" on the current version of FreeNAS leaves the "Version" field blank, and doesn't even pretend that it is doing anything cross-compatible.
I'm writing this post to help others avoid the same learning curve, but also to make a clear point to the home user: Avoid FreeNAS.
.