Joerg Schilling wrote:
Carsten Bormann <[EMAIL PROTECTED]> wrote:
On Dec 29 2007, at 08:33, Jonathan Loran wrote:
We snapshot the file as it exists at the time of
the mv in the old file system until all referring file handles are
closed, then destroy the single file snap. I know, not easy to
implement, but that is the correct behavior, I believe.
Exactly.
Note that apart from open descriptors, there may be other links to the
file on the old FS; it has to be clear whether writes to the file in
the new FS change the file in the old FS or not. I'd rather say they
shouldn't.
Yes, this would be different from the normal rename(2) semantics with
respect to multiply linked files. And yes, the semantics of link(2)
should also be consistent with this.
This in an interesting problem. Your proposal would imply that a file
may have different identities in different filesystems:
- different st_dev
- different st_ino
- different link count
This cannot be implemented with a single "inode data" anymore.
Well, it is not impossible as my WOFS (mentioned before) implements
hardlinks via "inode relative symlinks". In order to allow this. a file
would need a storage pool global serial number that allows to match different
inode sets for the file.
Jörg
At first, as I mentioned in my earlier email, I was thinking we needed
to emulate the cross-fs rename/link/etc behavior as it is currently
implemented, where a file appears to actually be copied. But now I'm
not so sure.
In Unixland, the ideal has always been to have the whole file system,
kit and caboodle, singly rooted at /. Heck, even devices are in the
file system. Of course, reality required that Programmatically, we
needed to be aware of what file system your cwd is in. At a minimum,
it's returned in our various stat structs (st_dev).
I can see I'm getting long winded, but I'm thinking: what is the value
of having different behavior with a cross zfs file move, within the same
pool as that between directories. I'm not addressing the previous
discussion about how to treat file handles, etc, but more about sharing
open file blocks, linked across zfs boundaries before and after such a mv.
I think the test is this: can we find a scenario where something would
break if we did share the file blocks across zfs boundaries after such a
mv? For every example I've been able to think of, if I ask the
question: what if I moved the file from one directory to the other,
instead of across zfs boundaries, would it have been different? it's
been no. Comments please.
Jon
--
- _____/ _____/ / - Jonathan Loran - -
- / / / IT Manager -
- _____ / _____ / / Space Sciences Laboratory, UC Berkeley
- / / / (510) 643-5146 [EMAIL PROTECTED]
- ______/ ______/ ______/ AST:7731^29u18e3
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
