All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: NeilBrown <neilb@suse.de>
Cc: linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org,
	paul.clements@steeleye.com
Subject: Re: [PATCH 002 of 8] md/bitmap: Remove bitmap writeback daemon.
Date: Fri, 12 May 2006 10:40:35 -0700	[thread overview]
Message-ID: <20060512104035.5fee4e66.akpm@osdl.org> (raw)
In-Reply-To: <1060512060736.8006@suse.de>

NeilBrown <neilb@suse.de> wrote:
>
>  ./drivers/md/bitmap.c         |  115 ++----------------------------------------

hmm.  I hope we're not doing any of that filesystem I/O within the context
of submit_bio() or kblockd or anything like that.  Looks OK from a quick
scan.

a_ops->commit_write() already ran set_page_dirty(), so you don't need that
in there.

I assume this always works in units of a complete page?  It's strange to do
prepare_write() followed immediately by commit_write().  Normally
prepare_write() will do some prereading, but it's smart enough to not do
that if the caller is preparing to write the whole page.

We normally use PAGE_CACHE_SIZE for these things, not PAGE_SIZE.  Same diff.

If you have a page and you want to write the whole thing out then there's
really no need to run prepare_write or commit_write at all.  Just
initialise the whole page, run set_page_dirty() then write_one_page().

Perhaps it should check that the backing filesystem actually implements
commit_write(), prepare_write(), readpage(), etc.  Some might not, and the
user will get taught not to do that via an oops.



  reply	other threads:[~2006-05-12 17:40 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-12  6:07 [PATCH 000 of 8] md/bitmap: Introduction - rework management of bitmap files NeilBrown
2006-05-12  6:07 ` [PATCH 001 of 8] md/bitmap: Fix online removal of file-backed bitmaps NeilBrown
2006-05-12  6:07 ` [PATCH 002 of 8] md/bitmap: Remove bitmap writeback daemon NeilBrown
2006-05-12 17:40   ` Andrew Morton [this message]
2006-05-13  3:14     ` Neil Brown
2006-05-13  6:59       ` Andrew Morton
2006-05-12  6:07 ` [PATCH 003 of 8] md/bitmap: Cleaner separation of page attribute handlers in md/bitmap NeilBrown
2006-05-12  6:07 ` [PATCH 004 of 8] md/bitmap: Use set_bit etc for bitmap page attributes NeilBrown
2006-05-12  6:07 ` [PATCH 005 of 8] md/bitmap: Remove unnecessary page reference manipulations from md/bitmap code NeilBrown
2006-05-12  6:07 ` [PATCH 006 of 8] md/bitmap: Remove dead code from md/bitmap NeilBrown
2006-05-12  6:08 ` [PATCH 007 of 8] md/bitmap: Tidy up i_writecount handling in md/bitmap NeilBrown
2006-05-12  6:08 ` [PATCH 008 of 8] md/bitmap: Change md/bitmap file handling to use bmap to file blocks NeilBrown
2006-05-12 17:47   ` Andrew Morton
2006-05-13  3:46     ` Neil Brown
2006-05-13  6:59       ` Andrew Morton
2006-05-13 15:29         ` Paul Clements
2006-05-13 15:42           ` Andrew Morton
2006-05-14 11:15             ` Neil Brown
2006-05-14 11:22               ` Andrew Morton
2006-05-15  0:26         ` Neil Brown
2006-05-15 21:04           ` Andrew Morton
2006-05-15 23:03             ` Neil Brown

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=20060512104035.5fee4e66.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=paul.clements@steeleye.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.