On Tue, Mar 18, 2014 at 06:55:13PM +0800, Liu Bo wrote: > On Mon, Mar 17, 2014 at 03:41:31PM +0100, David Sterba wrote: > > There are enough EINVAL's that verify correcntess of the input > > parameters and it's not always clear which one fails. The EOPNOTSUPP > > errocode is close to the true reason of the failure, but it could be > > misinterpreted as if the whole clone operation is not supported, so it's > > not all correct but IMO better than EINVAL. > > Yep, I was hesitating on these two errors while making the patch, but I > prefer EINVAL rather than EOPNOTSUPP because of the reason you've stated. > > I think it'd be good to add one more btrfs_printk message to clarify what's > happening here, agree?
I don't think a printk is the right thing here, this means that if an error happens somebody has to look into the log what happened and act accordingly. The EOPNOTSUPP errorcode would allow an application to do a fallback action, ie. copy the data instead of cloning. The same as if the clone ioctl would not exist at all. EINVAL says "you didn't give me valid arguments to work with". -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
