On 08/10/15 02:40, Neil Brown wrote:
> Anna Schumaker <[email protected]> writes:
>
>> @@ -1338,34 +1362,26 @@ ssize_t vfs_copy_file_range(struct file *file_in,
>> loff_t pos_in,
>> struct file *file_out, loff_t pos_out,
>> size_t len, unsigned int flags)
>> {
>> - struct inode *inode_in;
>> - struct inode *inode_out;
>> ssize_t ret;
>>
>> - if (flags)
>> + /* Flags should only be used exclusively. */
>> + if ((flags & COPY_FR_COPY) && (flags & ~COPY_FR_COPY))
>> + return -EINVAL;
>> + if ((flags & COPY_FR_REFLINK) && (flags & ~COPY_FR_REFLINK))
>> + return -EINVAL;
>> + if ((flags & COPY_FR_DEDUP) && (flags & ~COPY_FR_DEDUP))
>> return -EINVAL;
>>
>
> Do you also need:
>
> if (flags & ~(COPY_FR_COPY | COPY_FR_REFLINK | COPY_FR_DEDUP))
> return -EINVAL;
>
> so that future user-space can test if the kernel supports new flags?
Seems like a good idea, yes.
Also that got me thinking about COPY_FR_SPARSE.
What's the current behavior when copying a sparse range?
Is the hole propagated by default (good), or is it expanded?
Note cp(1) has --sparse={never,auto,always}. Auto is the default,
so it would be good I think if that was the default mode for copy_file_range().
With other sparse modes, we'd have to avoid copy_file_range() unless
there was control possible with COPY_FR_SPARSE_{AUTO,NONE,ALWAYS}.
Note currently cp --sparse=always will detect runs of zeros and also
avoid speculative preallocation by using fallocate (fd, FALLOC_FL_PUNCH_HOLE,
...)
thanks,
Pádraig.
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
