Messages in this thread | | | Date | Sun, 16 Jan 2000 04:41:22 -0500 (EST) | From | Alexander Viro <> | Subject | Re: why invalidate_buffers() in blkdev_put()? |
| |
On Sat, 15 Jan 2000, Mikael Pettersson wrote:
> In 2.3.39 a call to invalidate_buffers() was added to > fs/block_dev.c:blkdev_put(). > > Is it really necessary to forcibly throw away in-core cached > data just because the device was closed? > > The device is synced, so the cache is simply reclaimed if/when > that memory is needed later on, and check_media_change() is there > to invalidate the cache if the media has changed the next time > the device is opened.
There are some problems with that. Not that they were unsolvable, but...
a) for removable devices with partitions you can't leave the stale buffer_heads in the cache. Period. Otherwise you are in for trouble - partition-parsing code use buffer cache and does it prior to any chance to call check_media_change(). Fix: either insert the call of check_disk_change() (ugly, and prone to breakage) or make the fs/partitions work not through buffer cache.
b) there are different kinds of access. I.e. we may be going through buffer cache (open, loopback), through page cache (swapon), through mix of buffer and page caches (mount) or through none of them (raw devices). Driver doesn't know anything about that. What and how you should invalidate depends on that. blkdev_put()/blkdev_get()/blkdev_open() know what happens, so such stuff should be there. Fix: add logics that would trace such stuff accurately. I'll do that, but for now I just went for obviously correct variant. Lose of speed on floppy rereads for several releases is better than corrupted filesystems and partition tables...
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |