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 Thu, Sep 22, 2016 at 5:25 AM, Darrick J. Wong
<darrick.wong@xxxxxxxxxx> wrote:
> On Thu, Sep 22, 2016 at 08:33:31AM +1000, Dave Chinner wrote:
>> On Wed, Sep 21, 2016 at 10:57:24PM +0100, Al Viro wrote:
>> > On Thu, Sep 22, 2016 at 07:48:15AM +1000, Dave Chinner wrote:
>> >
>> > > If you get any error other than -EXDEV or -EOPNOTSUPP from a clone
>> > > operation, there's somethign seriously wrong with the metadata of
>> > > the inode or the underlying storage.
>> >
>> > Such as -ENOSPC?
>>
>> Yup, that's a fatal error, too.  i.e. if a clone returns ENOSPC
>> because there isn't space for the extra metadata, then the fallback
>> data copy is almost certainly going to fail with ENOSPC when trying
>> to reserve/allocate space for both the extra data copy and the extra
>> metadata....
>
> XFS will return ENOSPC during reflink if one of the relevant AGs is
> running low on space for the refcount/rmap trees; however there might be
> enough blocks in another AG to make a regular old copy.
>

That settles it then. I rather be prudent and retry copy anyway.
Other (maybe future) filesystems may have their own non-fatal reasons
to fail clone
and they have the right to do so.

I will resend the ACKed clone_range patch pair for Miklos to pick up

For now, I am not at ease about resending the copy_range patch pair
without a proper way for users to get independent test coverage for it.

Unless Miklos or Al feel confident enough about taking those patches
on my testing testimony and their review?

Darrick, do you have an easy way to reproduce the extreme case of
clone failure due to certain AG ENOSPC? any xfstest for it?
I recon that the fallback to copy_range could be useful in that case
(i.e. very large file with one block in the unfortunate AG)

Cheers,
Amir.
--
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