lkml.org 
[lkml]   [2001]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] invalidate buffers on blkdev_put


On Mon, 24 Sep 2001, Chris Mason wrote:

>
> Hi guys,
>
> I had sent this to Al, but couldn't tell if he hated it, thought it was
> broken, or just didn't think it was required. So, I opted for wider
> testing. This only affects 2.4.10pre15+, as it was caused by the blkdev
> changes there.
>
> Anyway, the bug looks like this:
>
> dd if=ext2-image-1 of=/dev/ram0
> mount /dev/ram0 /mnt
> umount /mnt
>
> dd if=ext2-image-2 of=/dev/ram0
> mount /dev/ram0 /mnt
> ls -la /mnt (FS looks corrupted and wrong).
>
> The problem is that on unmount, the ramdisk's buffer cache isn't cleared
> because bd_openers is still one. So, even if a new image is copied in, you
> still see the old image's superblock/inodes etc on mount.
>
> In this case, we want to leave the dirty pages in the page cache, but get
> rid of the buffer cache copies.
>
> This should not drop any updated data in the ramdisk because
> rd_blkdev_pagecache_IO dirties pages as the higher layers send down
> modified buffer heads (and other rd.c funcs do the same). Patch is below.
> Linus, please consider (pending lack of nays from Al).

OK, not exactly nay, but... What you are trying to do is a workaround
for problem that can be solved in somewhat saner way. Namely, we can
make getblk() return buffres backed by pages from device page cache.

It's _not_ an obvious step. The most sensitive parts are
* need to allocate all bdev pages with GFP_BUFFER. Otherwise
we'll eat flaming death on VM deadlocks. Doable (we can set ->i_data.gfp_mask)
but may lead to interesting effects wrt VM balancing.
* implementation of bforget()
* we'll need to kill buffer hash or deal with the new access path
to page-private buffer_heads.

It's solvable, but not obvious. It _does_ solve coherency problems between
device page cache and buffer cache (thus killing update_buffers() and its
ilk), but the last issue (new access path to page-private buffer_heads)
may be rather nasty.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:03    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site