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, n
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
> > impleme
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.
Exact
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 co
[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 ident
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
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
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:
>
> http:
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
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 k
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 b
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 th
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
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 ren
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 pie
Frank Hofmann <[EMAIL PROTECTED]> 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 with ENAMETOOLONG.
>
> 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 featu
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(
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;
> > va
>
>
>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:
>
> http://www.opengroup.org/o
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:
http://www.opengroup.org/onlinepubs/0
On Fri, 28 Dec 2007, Darren Reed wrote:
> [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.
>>>
>>>
[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 a
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 do
>
>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 allow data movement between filesystems within a poo
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 th
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
27 matches
Mail list logo
