Re: Partital Fix: Media-Change after generic-scsi-read

Ulrich Windl (Ulrich.Windl@rz.uni-regensburg.de)
Mon, 6 May 1996 10:23:24 +0200


On 3 May 96 at 7:54, Peter Fox wrote:

> > From: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
> > Date: Thu, 2 May 1996 10:01:40 +0200
> >
> > On 29 Apr 96 at 19:12, Peter Fox wrote:
> >
> > > Thomas Niederreiter <tn@bv.rz.fh-muenchen.de> wrote:
> > >
> > > > I do now force the kernel upon closing the sg-device to invalidate
> > > > the read-cache. I know this is brute-force attack, but it works me.
> > >
> > > I think all removable media should do this. It is a pain to have to eject
> > > the floppy and reinsert it to make sure that a tar df /dev/fd0 verifies the
> > > data on the floppy, not what's in the cache.
> >
> > It sounds more like a problem in tar. Can joe user invalidate buffers
> > belonging to a {device,file}? If so, tar should take advantage of it,
> > even if the device is not removable. That's what verify is about.
>
> It's not just tar, its every program that opens and closes /dev/fd0 directly.
> All it would take is to invalidate buffers if the device count reaches 0, or
> invalidate buffers if the device count is changed from 0 to 1. (Depending
> whether you want to do it on close or open)

Sorry, but I think you are wrong here: If a removable device has not
been changed, why would you invalidate the buffers? Just to make
verify in application programs easier? I think you should change the
application program, not the driver/kernel.

>
> Note that I'm not talking about a mounted device, which will obviously be
> buffered all the time it is mounted.
>
> [The tar example works on SunOS, with /dev/rfd0c, but I don't know if it
> has any buffering at all, as it's deperately slow]
>
> I think I'll look into making a patch...
>
> Peter.
Ulrich