On Tue, Nov 17, 2015 at 07:01:17PM -0800, Darrick J. Wong wrote:
> Current btrfs returns EINVAL if the file isn't open for writing or is
> append-only. I think EBADF captures the situation here better and
> it's what Anna is pushing for copy_file_range. We can make the
> change, but generic/157 will fail on old kernels if we do this.
As the old errno was rather wrong compared to similar syscalls I'd
say don't worry about this.
> One other thing I noticed -- prior to Anna's patchset, trying to
> invoke the reflink ioctl with a device, pipe, or socket as the
> destination could return a variety of error codes (-ENOTTY, -EINVAL,
> -ENOIOCTLCMD, etc.) which has all been replaced with -EOPNOTSUPP.
> That seems like a reasonable direction to take the test case.
>
> Does this seem like a reasonable addition to the plan?
-ENOIOCTLCMD should never reach userspace, this is a clear bug.
-EINVAL also seems wrong, but ENOTTY is perfectly valid for an
ioctl based implementation. So I'd say we should allow
ENOTTY or -EOPNOTSUPP in the test case by using filters, and ensure
btrfs and nfs only return those in 4.4 and maybe with backports to
stable.
> Should invalid inputs to the dedupe ioctl return the same error codes
> as the same invalid inputs to the reflink ioctl? I've been working on
> patches to hoist EXTENT_SAME to the VFS.
I think so. EXTENT_SAME is so similar to clone that it should almost be
a flag for it in the low level API.
|