Re: [PATCH v3 2/4] ovl: use vfs_clone_file_range() for copy up if possible

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Sep 21, 2016 at 7:01 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
> On Wed, Sep 21, 2016 at 6:09 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>> On Wed, Sep 14, 2016 at 2:43 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>>> When copying up within the same fs, try to use vfs_clone_file_range().
>>> This is very efficient when lower and upper are on the same fs
>>> with file reflink support. If vfs_clone_file_range() fails because
>>> lower and upper are not on the same fs or if fs has no reflink support,
>>> copy up falls back to the regular data copy code.
>>>
>>> Tested correct behavior when lower and upper are on:
>>> 1. same ext4 (copy)
>>> 2. same xfs + reflink patches + mkfs.xfs (copy)
>>> 3. same xfs + reflink patches + mkfs.xfs -m reflink=1 (reflink)
>>> 4. different xfs + reflink patches + mkfs.xfs -m reflink=1 (copy)
>>>
>>> For comparison, on my laptop, xfstest overlay/001 (copy up of large
>>> sparse files) takes less than 1 second in the xfs reflink setup vs.
>>> 25 seconds on the rest of the setups.
>>>
>>> Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx>
>>> ---
>>>  fs/overlayfs/copy_up.c | 12 +++++++++++-
>>>  1 file changed, 11 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c
>>> index 43fdc27..ba039f8 100644
>>> --- a/fs/overlayfs/copy_up.c
>>> +++ b/fs/overlayfs/copy_up.c
>>> @@ -136,6 +136,16 @@ static int ovl_copy_up_data(struct path *old, struct path *new, loff_t len)
>>>                 goto out_fput;
>>>         }
>>>
>>> +       /* Try to use clone_file_range to clone up within the same fs */
>>> +       error = vfs_clone_file_range(old_file, 0, new_file, 0, len);
>>> +       if (!error)
>>> +               goto out;
>>> +       /* If we can clone but clone failed - abort */
>>> +       if (error != -EXDEV && error != -EOPNOTSUPP)
>>> +               goto out;
>>
>> Would be safer to fall back on any error.
>>
>
> Agreed. Dave, since you suggested the 'softer' fall back, do you have
> any objections?
>
>> Otherwise ACK.
>>
>
> Will you be taking this to your tree?

Sure I can take it.

>
> Please note that this patch depends on patch v3 1/4,
> because vfs_clone_file_range() in current mainline
> fails to clone from lower to upper due to upper and lower being
> private mount clones
> and therefore not the same f_path.mnt.

Right.  I didn't do a thorough audit of ->clone_file_range()
implementations, but 1/4 is probably OK.

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



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux