On 2011-May-26 03:02:04 +0800, Matthew Ahrens <mahr...@delphix.com> wrote: >The first product of the working group is the design for a ZFS on-disk >versioning method that will allow for distributed development of ZFS >on-disk format changes without further explicit coordination. This >method eliminates the problem of two developers both allocating >version number 31 to mean their own feature.
Looks good.
>pool open ("zpool import" and implicit import from zpool.cache)
> If pool is at SPA_VERSION_FEATURES, we must check for feature
> compatibility. First we will look through entries in the label
> nvlist's features_for_read. If there is a feature listed there
> which we don't understand, and it has a nonzero value, then we
> can not open the pool.
Is it worth splitting "feature used" value into "optional" and
"mandatory"? (Possibly with the ability to have an "optional" read
feature be linked to a "mandatory" write feature).
To use an existing example: dedupe (AFAIK) does not affect read code
and so could show up as an optional read feature but a mandatory write
feature (though I suspect this could equally be handled by just
listing it in "features_for_write").
As a more theoretical example, consider OS-X resource forks? The
presence of a resource fork matters for both read and write on OS-X
but nowhere else. A (hypothetical) ZFS port to OS-X would want to
know whether the pool contained resource forks even if opened R/O
but this should not stop a different ZFS port from reading (and
maybe even writing to) the pool.
--
Peter Jeremy
pgpj1BokjEkft.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
