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-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
