Re: [PATCH v9 0/4] VFS: In-kernel copy system call

From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Eric Biggers <ebiggers3@gmail.com>,
	Anna Schumaker <Anna.Schumaker@netapp.com>
Cc: linux-nfs@vger.kernel.org, linux-btrfs@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org,
	zab@zabbo.net, viro@zeniv.linux.org.uk, clm@fb.com,
	darrick.wong@oracle.com, mtk.manpages@gmail.com,
	andros@netapp.com, hch@infradead.org
Subject: Re: [PATCH v9 0/4] VFS: In-kernel copy system call
Date: Thu, 12 Nov 2015 07:39:18 -0500	[thread overview]
Message-ID: <56448876.1030508@gmail.com> (raw)
In-Reply-To: <20151111145337.GA2392@zzz>

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

On 2015-11-11 09:53, Eric Biggers wrote:
> On Tue, Nov 10, 2015 at 04:53:30PM -0500, Anna Schumaker wrote:
>>        /* this could be relaxed once a method supports cross-fs copies */
>>        if (inode_in->i_sb != inode_out->i_sb)
>>                return -EXDEV;
>
> This allows the same superblock but different mounts --- is that intentional?
> The commit message says otherwise: it says the vfs entry point requires the same
> superblock and mount.
This could be important for BTRFS (because of subvolumes, you can have 
multiple mounts that have the same SB, and as of right now, it can be 
hard to tell the difference between a nested subvolume and a separate 
mount point).  We do support cross-subvolume reflinks, but I'm not sure 
if that works between subvolumes mounted at different places (if it 
doesn't, I may have to look into getting that changed).


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]