Alexander Viro writes:
> On Fri, 16 Jun 2000, Francis Galiegue wrote:
>> Second, there's the problem for data caching. My thoughts is
>> that this simply should NOT be done for PC floppies, and if one
>> is really paranoid, it should not even be done for other types
>> of r/w removable media (because pinhole).
>
> Caching is done not on a driver level. And if you will try to introduce
> gobs of special-case code into every filesystem - expect troubles.
Caching is broken if it does not keep the media busy writing data
(so keeping the floppy light on) until there is nothing to write.
Hardware should not sit idle while there is work to do.
The last thing to be done before turning off the floppy motor
should be marking the filesystem clean. The filesystems need
not know very much about this if anything; they only need to
respond to VFS requests that are very similar to umount & mount.
Caching is lame if it does not consider media performance and
administrative needs. We have swap priority because this is good.
>> Removing a floppy on a pending write just deserves the culprit
>> processes to be killed with SIGSEGV. When "the LED is on", the
>> floppy should not be ejected.
That would be SIGBUS on a page fault.
> Uh? We may be writing metadata and current process may have
> nothing to the situation - it just happened to apply memory
> pressure and trigger icache flush.
I think "flush" is indeed the right word here.
>> under a mount point which does not even exist? They can just
>> sit there and be happy, but we hold a dentry and an inode for
>> nothing. Any use of that
>
> Not possible. Define "nothing", please - what exactly do you propose?
>
>> mountpoint (readdir, open et al) would return EMEDIUMERROR.
>
> mountpoint? What about the stuff under it?
As long as the kernel can recover, the answer matters little.
The process can be given a current directory in some black hole
or given invisible parent directories with only ".." in them.
Files can return IO errors.
This is really just a forced umount.
-
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 : Fri Jun 23 2000 - 21:00:14 EST