From: David Sterba <dsterba@suse.cz>
To: Liu Bo <bo.li.liu@oracle.com>
Cc: linux-btrfs@vger.kernel.org, David Disseldorp <ddiss@suse.de>
Subject: Re: [PATCH] Btrfs: fix a crash of clone with inline extents's split
Date: Wed, 19 Mar 2014 19:47:16 +0100 [thread overview]
Message-ID: <20140319184716.GK29256@suse.cz> (raw)
In-Reply-To: <20140318105511.GA6163@localhost.localdomain>
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".
next prev parent reply other threads:[~2014-03-19 18:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-10 10:56 [PATCH] Btrfs: fix a crash of clone with inline extents's split Liu Bo
2014-03-17 14:41 ` David Sterba
2014-03-18 10:55 ` Liu Bo
2014-03-19 18:47 ` David Sterba [this message]
2014-04-09 17:42 ` David Disseldorp
2014-04-09 17:42 ` [PATCH] btrfs/035: update clone test to expect EOPNOTSUPP David Disseldorp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140319184716.GK29256@suse.cz \
--to=dsterba@suse.cz \
--cc=bo.li.liu@oracle.com \
--cc=ddiss@suse.de \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).