<div dir="ltr">It seems the ZFS-on-Linux team has taken the initiative and added a few pool features, that, when enabled, break write support on the other implementation of ZFS that I'm aware of, and, are enabled by default upon pool creation or upgrade unless explicitly disabled or the -n flag is specified.<div><br></div><div>Unfortunately they are enabled on the pool created by the ZFS graphical installer, which renders the pool read-only on most other implementations on most other operating systems, and even just old versions of ZoL.</div><div><br></div><div>So, I am just wondering if there's any support for the opinion that any pool features not universally or nearly universally be turned off by default, and frankly most of these are either unintelligible or practically useless even in the very specific use cases they were apparently (badly) designed for, so we won't be missing out on much. Consulting the chart we can see the worst offenders are 0.8 features like bookmarks_v2, project_quota, allocation_classes, resilver_defer. <br><div><br></div><div><a href="http://open-zfs.org/wiki/Feature_Flags">http://open-zfs.org/wiki/Feature_Flags</a><br></div><div><br></div><div>Yeah just look at this mess. Replacing ordered pool versioning numbers with an unordered set of random strings didn't turn out to be a very good idea IMO, and now we have to consult something like this considering all the ZFS implementations we're currently using and may or may not be using in the indefinite future. Of course sure you can backup the pool and create a new one without the flags, I just did in fact, but it seems like an unnecessary evil wrought by the chaos that is ZFS development in lieu of any open sourcing or leadership by Oracle that we can easily avoid.</div><div><br></div><div>Paul</div><div><br></div><div><a href="http://open-zfs.org/wiki/Feature_Flags"></a><div></div><div></div></div></div></div>