From: Andrew Morton <akpm@osdl.org>
To: marcus hall <marcus@tuells.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Block device swamping disk cache
Date: Wed, 12 May 2004 17:20:22 -0700 [thread overview]
Message-ID: <20040512172022.78d35f19.akpm@osdl.org> (raw)
In-Reply-To: <20040512133329.GA20030@bastille.tuells.org>
marcus hall <marcus@tuells.org> wrote:
>
> On Tue, May 11, 2004 at 05:26:43PM -0700, Andrew Morton wrote:
> > no, sorry, it'll still happen. I haven't fixed the ramdisk driver yet.
> >
> > The problem is that ->memory_backed means both "doesn't contribute
> > to dirty memory" and also "doesn't need writeback".
> >
> > These concepts need to be split apart for the ramdisk driver. I'll do it
> > for 2.6.7, promise.
>
> Well, I believe that the inodes that are marked as memory_backed are
> for the ramdisk, and that isn't really a problem. The block device
> that I am writing to is a compact flash, so it's going through the ide-disk
> device. I do not see this inode show up on any superblock's dirty queue
> (since it doesn't appear that mark_inode_dirty() is being called for
> it). So the question I am asking is, what strategy is *supposed* to be
> in place to flush the blocks out? (Or is this a hole that isn't plugged?)
Not sure why you're stuck running Krufty Old Kernels, but this patch from
June 2003 should fix it.
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2003/06/13 17:43:10-07:00 akpm@digeo.com
# [PATCH] fix writeback for dirty ramdisk blockdev inodes
#
# Once the blockdev inode for /dev/ram0 is dirtied we have a memory-backed
# inode on the blockdev superblock's s_dirty list.
#
# sync_sb_inodes() sees the memory-backed inode on the superblock and assumes
# that all the other inodes on the superblock are also memory-backed. This is
# not true for the blockdev superblock! We forget to write out dirty pages
# against the following blockdevs.
#
# Fix this by just leaving the inode dirty and moving on to inspect the other
# blockdev inodes on sb->s_io.
#
# (This is a little inefficient: an alternative is to leave dirtied
# memory-backed inodes on inode_in_use, so nobody ever even considers them for
# writeout. But that introduces an inconsistency and is a bit kludgey).
#
# fs/fs-writeback.c
# 2003/06/13 08:39:48-07:00 akpm@digeo.com +14 -1
# fix writeback for dirty ramdisk blockdev inodes
#
diff -Nru a/fs/fs-writeback.c b/fs/fs-writeback.c
--- a/fs/fs-writeback.c Wed May 12 17:18:54 2004
+++ b/fs/fs-writeback.c Wed May 12 17:18:54 2004
@@ -260,8 +260,21 @@
struct address_space *mapping = inode->i_mapping;
struct backing_dev_info *bdi = mapping->backing_dev_info;
- if (bdi->memory_backed)
+ if (bdi->memory_backed) {
+ if (sb == blockdev_superblock) {
+ /*
+ * Dirty memory-backed blockdev: the ramdisk
+ * driver does this.
+ */
+ list_move(&inode->i_list, &sb->s_dirty);
+ continue;
+ }
+ /*
+ * Assume that all inodes on this superblock are memory
+ * backed. Skip the superblock.
+ */
break;
+ }
if (wbc->nonblocking && bdi_write_congested(bdi)) {
wbc->encountered_congestion = 1;
next prev parent reply other threads:[~2004-05-13 0:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-11 19:11 marcus hall
2004-05-11 19:19 ` Christoph Hellwig
2004-05-11 19:48 ` marcus hall
2004-05-12 0:26 ` Andrew Morton
2004-05-12 13:33 ` marcus hall
2004-05-13 0:20 ` Andrew Morton [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-05-07 23:23 marcus hall
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=20040512172022.78d35f19.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcus@tuells.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
all inboxes | Powered by JetHome®