They often don't work the same because of the memory management between the OSes. Solaris tunables often don't exist in FreeBSD and vice versa. You know that solaris does things totally different from FreeBSD? They have a unified memory architecture, and that makes ZFS a wholly different beast.
Openzfs vs maczfs portable#
I haven't tried or needed to import a pool from another system, but shouldn't these issues be clearly documented somewhere?Īs far as I can tell, the documentation only identifies pools as being portable among platforms. Something like that would be good to know about (and filed as a bug to be fixed), but aside from references to anecdotes claiming that pool failure was due to a non-FreeNAS pool, I haven't seen any evidence that it's an issue. To reiterate, I'm looking for something like a known issue where a pool that is created on another system can be imported successfully into FreeNAS (versions and flags being compatible), but the pool will fail because FreeNAS assumes it's "layed out" in a certain way (what does that mean?), but fails to check that it actually is. Isn't there metadata on the drives that identify the devices? I know I've seen pools in FreeNAS with devices that weren't labeled with gptid. I don't think the way FreeNAS identifies the devices matters for compatibility either. Feature flags and versions are already handled by the zfs / zpool tools to manage compatibility and divergence. And the FreeNAS to Solaris example is the same. For one, disks of differing sizes are already a known issue even when trying to replace a drive in a pool that was created with FreeNAS.
Openzfs vs maczfs manual#
I'm not aware of the manual pointing out any (non-version related) incompatibilities with pools from other OSs.Īnd the issues you've pointed out aren't unique to FreeNAS. Simply referring to how the "pools are layed out" and "sporadic reports" doesn't clarify much. If this is actually the direction FreeNAS is headed, why not just change the name to avoid any ambiguity? At the least I'd think these "assumptions" need to be documented so users can account for them. Aside from implementation bugs, why would a ZFS volume created on one implementation be incompatible with another implementation? Do I need to worry that tar/gzip/etc files created on other platforms won't be compatible with FreeNAS? Are there assumptions made for other "standard" tools that lead to incompatibility with the FreeNAS implementation? I think ultimately it just feels weird/odd/wrong for an implementation to make decisions that break compatibility with others. Plus, the whole feature flags paradigm was intended to allow the open source ZFS implementations to move past the closed source Oracle version and allow for divergence and compatibility among the different forks. I get that in most cases each operating system supplies their own implementation of ZFS, but I've never seen it advertised as FreeNAS's ZFS.
Click to expand.Because ZFS is a common filesystem, not a unique feature of FreeNAS.
0 kommentar(er)
