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.
>>>
>>>
> such a minor "feature"
I don't think copying files is a minor feature.
Doubly so since the words I've read from Sun suggest that ZFS "file systems"
(or "data sets" or whatever they are called now) can be used in the way
directories on a normal file system are used.
This message posted f
[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
28 matches
Mail list logo
