The obvious pain points from my perspective would be the feature flag disparities between platforms, and how they bite people who get asked to try reproducing problems on other platforms. (Two examples that stick in my mind - multi_vdev_crash_dump unavailable on ZoL for a long time, and now the worse inverse of large_dnode only on ZoL.)
In particular, when ZoL 0.8.x comes out, we'll have at least 5 feature flags that no other platform supports, one of which is not RO-compatible. [1] (This is great for ZoL importing things from other platforms, less so the reverse.) I'd argue that it'd be nice to have something like zpool create -X compat=123 which restricts the feature flag set to known subsets that most/all platforms supported at that point, without having to remember the enumeration of flags that won't shoot you in the foot as of $DATE. (Yes, pool creation is an uncommon event for most, but IMO the default behavior should not be to end up with a pool no other platform can import.) But that's just me having had to explain to many people why their pool wouldn't import elsewhere when a bug on one platform bit them and they wanted to try another. - Rich On Wed, Nov 28, 2018 at 6:36 AM Igor Kozhukhov <i...@dilos.org> wrote: > > Hello All, > > could you please let me know : what are problems with ZFS on Linux, FreeBDS, > OSX and others ports? > > For example: > on Linux we have problems with poweroff - pool can be unavailable and need > some dance for restore it (with lustre node, etc) > > what are problems with ithers? > > best regards, > -Igor > ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/T1ce8db6589272d89-Ma2240404d27f5c96e37f8a47 Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
