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. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
