By the way, I sent a couple wishlist items for nfsd to Daniel in private
mail that probably should have gone to the list. For now my
understanding is that nfsd exports aren't even supported, but for the
future a couple things that would be useful on a new filesystem are:
- a change attribute (see the new file-versioning stuff that
went into ext4, which I haven't hooked the nfs server up to
yet--my bad): an integer which increases each time the file
data or metadata changes (basically, whenever ctime would be
considered for updating), needed for correct cache coherency
with nfsv4 clients (otherwise we use ctime and run into
time-resolution problems, even on filesystems that support
high-precision times)
- Anything to ease creation of new volumes on the fly, either in
the filesystem itself or a volume manager underneath.
Otherwise people try to export subtrees, which has a number of
problems, not least that we can't really enforce them as a
security boundary: when we get a filehandle, there's no
efficient way to check whether the inode it points to is
accessible under an exported subtree.... We'd really like to
get people to the point where they only ever support entire
filesystems, but we won't get to that point without easier
management.
--b.
_______________________________________________
Tux3 mailing list
[email protected]
http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3
