linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Alex Tomas <alex@clusterfs.com>
Cc: linux-ext4@vger.kernel.org, <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] ext4-delayed-allocation.patch
Date: Sat, 23 Dec 2006 14:59:07 -0800	[thread overview]
Message-ID: <20061223145907.c7e09a8b.akpm@osdl.org> (raw)
In-Reply-To: <m3tzznvfnz.fsf@bzzz.home.net>

On Fri, 22 Dec 2006 23:28:32 +0300
Alex Tomas <alex@clusterfs.com> wrote:

> +/*
> + * With EXT4_WB_SKIP_SMALL defined the patch will try to avoid
> + * small I/Os ignoring ->writepages() if mapping hasn't enough
> + * contig. dirty pages
> + */
> +#define EXT4_WB_SKIP_SMALL__
> +
> +#define WB_ASSERT(__x__) if (!(__x__)) BUG();

This is unused.  Please kill.

> +#define WB_DEBUG__
> +#ifdef WB_DEBUG
> +#define wb_debug(fmt,a...)	printk(fmt, ##a);
> +#else
> +#define wb_debug(fmt,a...)
> +#endif

It's tiresome for each piece of kernel code to implement private debug
macros.  Why not use pr_debug()?

In general, this patch adds a mountain of code which I suspect just
shouldn't be in a filesystem.  It should be library code in mm/ or fs/. 
It'll take some thought and refactoring and definition of new
address_space_operations entries, etc.  But burying all this inside a
single filesystem is just The Wrong Thing To Do.

I am not inclined to review the code in detail because the lack of suitable
code comments would make that task much larger and significantly less
useful than it should be.  Please spend a day or so commenting the code in
a similar manner to other parts of ext4 and jbd2.  When doing so, put
yourself in the position of an experienced kernel developer who seeks to
understand what the code is doing and why it is doing it.  Skilful
commenting is essential if the code is to be maintainable and it has an
immediate impact upon the code's quality.  Every non-trivial function
should have an introductory comment which tells the reader why this
function exists, what it does and, if not obvious, how it does it.  Don't
bother with kernel-doc comments - for some reason they tend to be useless
for code conprehension.

I shouldn't need to sit here scratching my head and wondering why the heck
a writepages function is running __set_page_dirty_nobuffers().

Thanks.

  reply	other threads:[~2006-12-23 22:59 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-22 20:20 [RFC] delayed allocation for ext4 Alex Tomas
2006-12-22 20:23 ` [RFC] booked-page-flag.patch Alex Tomas
2006-12-22 20:25 ` [RFC] ext4-block-reservation.patch Alex Tomas
2006-12-23 22:40   ` Andrew Morton
2006-12-23 22:47     ` Alex Tomas
2006-12-22 20:28 ` [RFC] ext4-delayed-allocation.patch Alex Tomas
2006-12-23 22:59   ` Andrew Morton [this message]
2007-01-12 14:45   ` Valerie Clement
2007-01-12 14:52     ` Alex Tomas
2006-12-23  3:31 ` [RFC] delayed allocation for ext4 David Chinner
2006-12-23  9:27   ` Christoph Hellwig
2006-12-23 19:15     ` Alex Tomas
2006-12-29  2:50     ` David Chinner
2006-12-23 19:09   ` Alex Tomas
2006-12-29  2:52     ` David Chinner
2006-12-29  4:56       ` Alex Tomas

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=20061223145907.c7e09a8b.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=alex@clusterfs.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@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).