Messages in this thread |  | | From | "Ulrich Windl" <> | Date | Mon, 6 May 1996 10:23:24 +0200 | Subject | Re: Partital Fix: Media-Change after generic-scsi-read |
| |
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
|  |