Btrfs devel - Mar 2011 - [PATCH] btrfs: return EXDEV when linking from different subvolumes

btrfs_link returns EPERM if a cross-subvolume link is attempted.

However, in this case I believe EXDEV to be the more appropriate value.
From the link(2) man page:

EXDEV  oldpath and newpath are not on the same mounted file system.  (Linux
       permits a file system to be mounted at multiple points, but link()
       does not work across different mount points, even if the same file
       system is mounted on both.)

This matters because an application may have different behaviors based on
return codes.

Signed-off-by: Mark Fasheh <mfasheh@suse.com>

---
 fs/btrfs/inode.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 512c3d1..321ce4c 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -4809,7 +4809,7 @@ static int btrfs_link(struct dentry *old_dentry, struct
inode *dir,
 
 	/* do not allow sys_link''s with other subvols of the same device */
 	if (root->objectid != BTRFS_I(inode)->root->objectid)
-		return -EPERM;
+		return -EXDEV;
 
 	btrfs_inc_nlink(inode);
 	inode->i_ctime = CURRENT_TIME;
-- 
1.6.4.2

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Tue, Mar 22, 2011 at 1:20 PM, Mark Fasheh <mfasheh@suse.com>
wrote:
> btrfs_link returns EPERM if a cross-subvolume link is attempted.
>
> However, in this case I believe EXDEV to be the more appropriate value.
> From the link(2) man page:
This makes makes sense, that''s the behavior link(2) normally returns.
However, ln(1) doesn''t attempt
the link at all across separate filesystems - it checks fstat(...
.st_dev) on the source an destination.  On
suvolumes, that''s the same.    It''s a slight userspace
difference and
I''m not sure it matters.

However, what stops hardlinks across subvolumes?  I understand that
when you delete a subvolume
you''ll have to recurse through to decrease the link count and possibly
drop the inode, but Isn''t there a
scan going on already for the CoW blocks created by snapshot?   What''s
the difference between a hardlink
made across subvolumes and a hardlink cloned when a snapshot is made?

I ask because I hit that when sorting 10 years of downloads/camera
offloads/documents etc and I wanted
to not duplicate the enormous amount of storage into the new volume.
I ended up just biting the bullet and
duplicating 250gb - I''ve got an unfortunate "filesystem as it
was"
backup subvolume which will retain the blocks
even if the current /home is cleaned up.   As a workaround I could
find huge files and delete them on the backup, but
it would seem that using link(2) to tell btrfs that these blocks will
be the same makes it trivial to do from userspace.


Addendum:  BTRFS subvolumes:
/sorted
/home-as-it-was
/home (pruned lost but valuable files)
(daily snapshots of /sorted and /home)

home-as-it-was was made by using rsync on /home to /home-as-it-was,
/home was a snapshot, and /sorted was created as it''s own subvolume.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html