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. 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. Nico -- _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
