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.
> It is a misdesign of the buffer cache. [Wait until 2.5 before repairing.]
> The current state of affairs causes strange things around fdisk
> and various partition repair programs.
Note that my suggestion for this particular thing (and all classes of
these things) is very simple:
- fsync the buffer cache at each close (we do this already, I think)
- throw the buffer cache away completely whenever there are no open users
of the block device.
Yes, right now the "cache the floppy contents around opens" is really nice
for things like "mtools" etc, which open and close the floppy device all
the time and as long as we cache it globally we're cool.
But the advantage is pretty small, and not really worth it.
The advantage of NOT caching the contents across opens is that if you
don't do it, then not only don't you have aliasing issues (well, you do
while it's open, but it's something we can educate installers about etc),
but you also can do your indexing on arbitrary data structures that only
exist while the device is open (ie you can allocate the disk structures
dynamically - and still use them as the index to the cache, even though
they go away and re-appear as they see fit).
It also mixes well with drivers that go away dynamically, and is just
generally the right thing to do in a dynamic environment. For example, it
makes disk change issues almost go away - you no longer end up depending
on having a 100% reliable disk change detect mechanism (if somebody
changes the disk while we're holding it open, the failure is at least
reasonably _explainable_ with a "don't do that then" kind of argument).
In fact, for floppies we could probably just get rid of the disk change
detection, and nobody would ever even notice. Not that I'm advocating
this: I think detecting disk changes is a good thing anyway, I'm just
saying that if I had done this originally, I wouldn't ever have bothered.
The mark of a good design is how many unrelated problems it solves, and
how simple it is. This one solves just about everything.
(Note that for any practical use, the change of buffering semantics
doesn't mean a thing: anybody who mounts a device will keep it open
through the mount, of course. And people who do databases on raw devices
will certainly not be opening and closing the device all the time
either. So for most things you'd never really notice at all).
Linus
-
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:13 EST