On Sun, 16 Jan 2000, Guest section DW wrote:
>On the other hand, a problem that does occur is the aliasing
>between block 15003 of hda and block 3 of hda2.
This is an interesting problem indeed (and a one I never noticed before
reading your email :).
>It is a misdesign of the buffer cache. [Wait until 2.5 before repairing.]
The invalidate_buffers() as Linus suggests will make harder the problem to
reproduce, so you could notice it only if you'll read from /dev/hda and
while you take the /dev/hda fd open, you'll also write to /dev/hda2 and
then you'll read again from hda.
I believe the complete and correct fix for this incoherency is just to fix
it at the source of the problem. Basically I believe the right fix is to
make get_hash_table() to return the _same_ buffer for both the (hda,15003)
and (hda2,3) pairs. It won't need any kind of
racy-cross-dev-invalidating-upon-write-to-disk, but it will only need a
change into the input of the hashfunction and into get_hash_table while
searching into the hash-collision-list. It will be a per-blockdevice
callback to do the block/dev conversion for us. It will indeed cost some
precious CPU cycle though... (OTOH buffer cache hash performance are less
critical these days (and dbms uses rawio) so we could be not too much
worried about that). In our example the per-blockdevice callback should
convert the dev from hda2 to hda and to add a 15000 wide offset to the
blocknr.
Maybe I am overdesigning and we should only band-aid the effect this time?
Another simple option would be to trunc hda to not overlap on hda2 but I
don't like this option very much...
Comments?
Andrea
-
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/
This archive was generated by hypermail 2b29 : Sun Jan 23 2000 - 21:00:14 EST