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.
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
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,
On Jan 2, 2008 11:46 AM, Darren Reed [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
...
That's a sad situation for backup utilities, by the way - a backup
tool would have no way of finding out that file X on fs A already
existed as file Z on fs B. So what ? If the file got copied, byte
[EMAIL PROTECTED] wrote:
...
That's a sad situation for backup utilities, by the way - a backup
tool would have no way of finding out that file X on fs A already
existed as file Z on fs B. So what ? If the file got copied, byte by
byte, the same situation exists, the contents are
Frank Hofmann wrote:
On Fri, 28 Dec 2007, Darren Reed wrote:
[ ... ]
Is this behaviour defined by a standard (such as POSIX or the
VFS design) or are we free to innovate here and do something
that allowed such a shortcut as required?
Wrt. to standards, quote from:
On Mon, 31 Dec 2007, Darren Reed wrote:
Frank Hofmann wrote:
On Fri, 28 Dec 2007, Darren Reed wrote:
[ ... ]
Is this behaviour defined by a standard (such as POSIX or the
VFS design) or are we free to innovate here and do something
that allowed such a shortcut as required?
Wrt. to
Darren Reed [EMAIL PROTECTED] wrote:
Wrt. to standards, quote from:
http://www.opengroup.org/onlinepubs/009695399/functions/rename.html
ERRORS
The rename() function shall fail if:
[ ... ]
[EXDEV]
[CX] The links named by new and old are on different file
Joerg Schilling wrote:
Jonathan Edwards [EMAIL PROTECTED] wrote:
since in the current implementation a mv between filesystems would
have to assign new st_ino values (fsids in NFS should also be
different), all you should need to do is assign new block pointers in
the new side of the
On Dec 29, 2007, at 2:33 AM, Jonathan Loran wrote:
Hey, here's an idea: 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
Jonathan Edwards [EMAIL PROTECTED] wrote:
On Dec 29, 2007, at 2:33 AM, Jonathan Loran wrote:
Hey, here's an idea: 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
On Fri, 28 Dec 2007, Darren Reed wrote:
[ ... ]
Is this behaviour defined by a standard (such as POSIX or the
VFS design) or are we free to innovate here and do something
that allowed such a shortcut as required?
Wrt. to standards, quote from:
Darren Reed [EMAIL PROTECTED] wrote:
if (fromvp != tovp) {
vattr.va_mask = AT_FSID;
if (error = VOP_GETATTR(fromvp, vattr, 0, CRED(), NULL))
goto out;
fsid = vattr.va_fsid;
vattr.va_mask =
Frank Hofmann [EMAIL PROTECTED] wrote:
I don't think the standards would prevent us from adding cross-fs rename
capabilities. It's beyond the standards as of now, and I'd expect that
were it ever added to that it'd be an optional feature as well, to be
queried for via e.g. pathconf().
Why
On Fri, 28 Dec 2007, Joerg Schilling wrote:
Frank Hofmann [EMAIL PROTECTED] wrote:
I don't think the standards would prevent us from adding cross-fs rename
capabilities. It's beyond the standards as of now, and I'd expect that
were it ever added to that it'd be an optional feature as well,
On Fri, 28 Dec 2007, Joerg Schilling wrote:
[ ... ]
POSIX grants that st_dev and st_ino together uniquely identify a file
on a system. As long as neither st_dev nor st_ino change during the
rename(2) call, POSIX does not prevent this rename operation.
Clarification request: Where's the piece
Frank Hofmann [EMAIL PROTECTED] wrote:
On Fri, 28 Dec 2007, Joerg Schilling wrote:
[ ... ]
POSIX grants that st_dev and st_ino together uniquely identify a file
on a system. As long as neither st_dev nor st_ino change during the
rename(2) call, POSIX does not prevent this rename
Frank Hofmann wrote:
On Fri, 28 Dec 2007, Joerg Schilling wrote:
...
Why do you beliece there is a need for a pathconf() call?
Either rename(2) succeeds or it fails with a cross-device error.
Why do you have a NAME_MAX / SYMLINK_MAX query - you can just as well let
such requests fail
Joerg Schilling wrote:
See: http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html
The st_ino and st_dev fields taken together uniquely identify the file
within
the system.
The identity of an open file cannot change during the lifetime of a process.
Note that the renamed
Darren Reed [EMAIL PROTECTED] wrote:
Having just done a largish mv from one ZFS filesystem to another ZFS
filesystem in the same zpool, I was somewhat surprised at how long it
took - I was expecting it to be near instant like it would be within the
same filesystem.
I would guess that this is
On Thu, 27 Dec 2007, [EMAIL PROTECTED] wrote:
I would guess that this is caused by different st_dev values in the new
filesystem. In such a case, mv copies the files instead of renaming them.
No, it's because they are different filesystems and the data needs to be
copied; zfs doesn't
[EMAIL PROTECTED] wrote:
On Thu, 27 Dec 2007, [EMAIL PROTECTED] wrote:
I would guess that this is caused by different st_dev values in the new
filesystem. In such a case, mv copies the files instead of renaming
them.
No, it's because they are different filesystems and the data needs to
Having just done a largish mv from one ZFS filesystem to another ZFS
filesystem in the same zpool, I was somewhat surprised at how long it
took - I was expecting it to be near instant like it would be within the
same filesystem.
Are there optimisations possible here?
Surely it should be possible
23 matches
Mail list logo
