[sorry again, this message may arrive twice :(]
Hi,
I've read only part of the thread going on wrt floppy handling, but this is
not only about floppies, but all removable medium management in general. Here
are my thoughts about it. Bear in mind that the only experience I have with VFS
is what I could learn from reading all fs/*, that my experience with VM is only
limited to "I know the basic principles".
First, there is the problem of allowing/forbidding medium removal, which
cannot be done on floppies. IDE/SCSI floppies/CDROMs can do it. But as Richard
pointed to me in private, many of them also have a pinhole to force brute
ejection.
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).
Let's forget floppies for a little and concentrate on "smart" removable
media. What can be done for these is forcing synchronous writes in the limit of
what's bearable (ie, that a 2M write on a ZIP not make the system crawl), allow
ejection when all pending writes are done. From what I've read along the
thread, you can know when the eject button has been pressed - if this is true,
then you can queue the eject command after all pending writes, and all
subsequent writes and reads from the medium would return -EMEDIUMERROR.
Mmap()ed accesses can be killed with SIGSEGV. Tell me if I miss something.
Back to floppies: the solution of caching read/write operation from floppies
and prompting the user for reinserting medium x or y is IMNSHO unacceptable.
Even if you manage to get a unique id for a floppy, don't forget dd. The
floppy and its copy would be totally identical, byte by byte, and in case you
reinsert the wrong one, you find yourself with a fubar fs - on BOTH floppies.
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.
Period. Up to the user to behave.
Now stays the problem of usage count, open()ed files, etc. Supermount made it
so that a cwd under the mount point of a medium was not counted as opened, and
therefore it could rely on this in order to allow/forbid ejection - on smart
media, that is. What to do with processes which, after medium ejection, are
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
mountpoint (readdir, open et al) would return EMEDIUMERROR.
The way I see an implementation is to make another mount flag, and this mount
flag would have another effect: either allow the use of medium as a fs or a
raw device, but not both. If a process tries and opens the medium by itself
while there's a mounted fs should return -EBUSY and vice versa. I don't have
much time to implement it by myself (to be accurate, weekends only) but I want
to do it. I wish that I were not alone, or even better, that someone more
knowledgeable than I did it. In all cases, I'm keen on helping - and learning.
But we need to decide on an implementation.
Comments?
-- fg"You can tune a filesystem but you can't tuna fish" (HP/UX' tunefs manpage)
- 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:12 EST