On Wed, May 25, 2011 at 3:08 PM, Peter Jeremy <
peter.jer...@alcatel-lucent.com> wrote:
> On 2011-May-26 03:02:04 +0800, Matthew Ahrens <mahr...@delphix.com> wrote:
>
> Looks good.
>
Thanks for taking the time to look at this. More comments inline below.
> >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").
>
I'm not sure I understand the "optional" idea. How would an "optional read
feature" change the behavior, as opposed to just being listed in
"features_for_write"? If dedup'd pools can be read by old code that
doesn't understand dedup, then the dedup feature should be listed in
"features_for_write", and not "features_for_read".
> 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.
>
A hypothetical resource fork feature would probably be a ZPL (filesystem)
feature, rather than a pool feature, but that doesn't really change your
question.
If the presence of a resource fork doesn't preclude old code from reading or
writing it, but the MacOS code needs to know, "are there any resource forks
in this filesystem", then this can be handled in a way specific to the
resource fork code. For example, with a new entry in the MASTER_NODE_OBJ,
which only the resource fork code would care about; other code would ignore
it. So this can be handled seamlessly, outside the scope of the feature
flags proposal.
However, it's more likely that old code would not be able to safely write to
a filesystem with resource forks (for example, to know how to free the
resource fork when a file is removed). In this case, resource forks would
be a "feature for write". The MacOS code could use the features_for_write
to determine the presence of resource forks, even if opening the filesystem
read-only.
--matt
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
