On Oct 8, 2006, at 23:54, Nicolas Williams wrote:
On Sun, Oct 08, 2006 at 11:16:21PM -0400, Jonathan Edwards wrote:
On Oct 8, 2006, at 22:46, Nicolas Williams wrote:
You're arguing for treating FV as extended/named attributes :)
kind of - but one of the problems with EAs is the increase/bloat in
the inode/dnode structures and corresponding incompatibilities with
other applications or tools.
This in a thread where folks [understandably] claim that storage is
cheap and abundant. And I agree that it is.
Plus, I think you may be jumping to conclusions about the bloat of
extended attributes:
Another approach might be to put it all
into the block storage rather than trying to stuff it into the
metadata on top. If we look at the zfs on-disk structure instead and
simply extend the existing block pointer mappings to handle the diffs
along with a header block to handle the version numbers - this might
be an easier way out rather than trying to redefine or extend the
dnode structure. Of course you'd still need a single attribute to
flag reading the version block header and corresponding diff blocks,
but this could go anywhere - even a magic acl perhaps .. i would
argue that the overall goal should be aimed toward the reduction of
complexity in the metadata nodes rather than attempting to extend
them and increase the seek/parse time.
Wait a minute -- the extended attribute idea is about *interfaces*,
not
internal implementation. I certainly did not argue that a file
version
should be copied into an EA.
true, but I just find that the EA discussion is just as loaded as the FV
discussion that too often focuses on improvements in the metadata
space rather than the block data space. I'm not talking about the file
version data .. rather the bplist for the file version data and possibly
causing this to live in the block data space instead of the dnode
DMU. This way the FV will be completely accessible within the
filesystem block data structure instead of being abstracted back out
of the dnode DMU. I would hold that the version data space
consumption should also be readily apparent on the filesystem level
and that versioned access should not impede the regular file
lookup or attribute caching. It's a slight deviation from the typical
EA approach, but an important distinction to make to keep the
metadata structures relatively lean.
Let's keep interface and implementation details separate. Most of
this
thread has been about interfaces precisely because that's what users
will interact with; users won't care one bit about how it's all
implemented under the hood.
I'm not so sure you can separate the two without creating a hack. I
would also argue that users (particularly the ones creating the
interfaces) will care about the implementation details since those
are the real underlying issues they'll be wrestling with.
.je
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
