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 9:29 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> 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.
>

Miklos,

Will you be able to queue v4 patches for 4.9?

Thanks,
Amir.

>>
>> 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