linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: Akira Fujita <a-fujita@rs.jp.nec.com>
Cc: Peng Tao <bergwolf@gmail.com>,
	Greg Freemyer <greg.freemyer@gmail.com>,
	linux-ext4@vger.kernel.org
Subject: Re: [PATCH 3/4]ext4: Return exchanged blocks count to user space in  failure
Date: Sat, 5 Sep 2009 23:37:15 -0400	[thread overview]
Message-ID: <20090906033715.GF3055@mit.edu> (raw)
In-Reply-To: <4AA0E419.7010707@rs.jp.nec.com>

On Fri, Sep 04, 2009 at 06:55:37PM +0900, Akira Fujita wrote:
> 
> More test cases are needed for EXT4_IOC_MOVE_EXT,
> so this patch may not be complete,
> but the problem you reported is fixed at least.
> I am now testing EXT4_IOC_MOVE_EXT hard.

I've not added this patch to the patch queue, yet, based on the fact
that are still doing more testing and Pen Tao seems to have found more
issues.

I have applied your original four patches since I've looked over the
patches and they look good.

Two comments I have of the move_extents() code; it would be preferable
if you replace BUG_ON calls with a call to ext4_error(); that way
instead of crashing the entire kernel, you print an error and then
stop making changes to the file system in question.  Users will be
much happier if the system doesn't completely crash, and it also
becomes easier to grab the system messages after an ext4_error(),
compared to BUG_ON().   

Secondly, it would be really nice to replace get_ext_path() with an
inline function.  The problem with get_ext_path() is that for someone
who is just reading through the code it looks like a function call,
but the first and fourth arguments get modified.  But if someone
doesn't jump up to the beginning of the call, this isn't obvious.

If I can't look at the #define, it's not obvious that orig_path and
err will be modified.

	get_ext_path(orig_path, orig_inode, eblock, err);

A calling path like this is much more obvious:

	err = get_ext_path(orig_inode, eblock, &orig_path);

See?  Just one look at the 2nd calling pattern makes it obvious that
err and orig_path functions will be modified.  And returning the error
code (as a negative errno code) is a common calling convention used in
the kernel.

Rusty's slides about interface design are especially good to review in
this context:

	http://ozlabs.org/~rusty/ols-2003-keynote/img27.html

(His whole slide deck are good to review, but this section is
especially valuable.)

						- Ted

  parent reply	other threads:[~2009-09-06  3:37 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-02  3:18 [PATCH 3/4]ext4: Return exchanged blocks count to user space in failure Akira Fujita
2009-09-02 15:54 ` Peng Tao
2009-09-02 20:59   ` Greg Freemyer
2009-09-03  5:13     ` Peng Tao
2009-09-03 13:48       ` Greg Freemyer
2009-09-04  3:35         ` Peng Tao
2009-09-04  9:55       ` Akira Fujita
2009-09-04 16:43         ` Peng Tao
2009-09-08  4:11           ` Akira Fujita
2009-09-08  8:00             ` Peng Tao
2009-09-11  5:06               ` Akira Fujita
2009-09-11  5:28                 ` Peng Tao
2009-09-11 16:57                 ` Peng Tao
2009-09-14  6:16                   ` Akira Fujita
2009-09-06  3:37         ` Theodore Tso [this message]
2009-09-06  3:13 ` Theodore Tso

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=20090906033715.GF3055@mit.edu \
    --to=tytso@mit.edu \
    --cc=a-fujita@rs.jp.nec.com \
    --cc=bergwolf@gmail.com \
    --cc=greg.freemyer@gmail.com \
    --cc=linux-ext4@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).