Messages in this thread |  | | Date | Mon, 24 Sep 2001 23:52:46 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: [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/
|  |