On Oct 8, 2006, at 22:46, Nicolas Williams wrote:
On Sun, Oct 08, 2006 at 10:28:06PM -0400, Jonathan Edwards wrote:
On Oct 8, 2006, at 21:40, Wee Yeh Tan wrote:
On 10/7/06, Ben Gollmer <[EMAIL PROTECTED]> wrote:
Hmm, what about file.txt -> ._file.txt.1, ._file.txt.2, etc? If you
don't like the _ you could use @ or some other character.
It does not matter which delimiter you use. I still want my "for
i in
*; do ..." to work as per now.
.<prefix> might be acceptable, but I rubs me the wrong way because of
this:
We want to differentiate files that are created intentionally from
those that are just versions. If files starts showing up on their
own, a lot of my scripts will break. Still, an FV-aware
shell/program/API can accept an environment setting that may quiesce
the version output. E.g. "export show-version=off/on".
Exactly.
if we're talking implementation - i think it would make more sense to
store the block version differences in the base dnode itself
rather than
creating new dnode structures to handle the different versions.
You'd
then structure different tools or flags to handle the versions (copy
them
to a new file/dnode, etc) - standard or existing tools don't need to
know
about the underlying versions.
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. 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.
.je
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
