lkml.org 
[lkml]   [2000]   [Jan]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.060 / U:0.772 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site