[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 be
>> copied; zfs doesn't allow data movement between filesystems within a
>> pool.
>
> It's not ZFS that blocks this by design - it's the VFS framework.
> vn_rename() has this piece:
>
> /*
> * Make sure both the from vnode directory and the to directory
> * are in the same vfs and the to directory is writable.
> * We check fsid's, not vfs pointers, so loopback fs works.
> */
> 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 = AT_FSID;
> if (error = VOP_GETATTR(tovp, &vattr, 0, CRED(), NULL))
> goto out;
> if (fsid != vattr.va_fsid) {
> error = EXDEV;
> goto out;
> }
> }
>
> ZFS will never even see such a rename request.
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?
Although I'm not sure the effort required would be worth the
added complexity (to VFS and ZFS) for such a minor "feature".
Darren
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
