I've been listening with interest because I've
used systems that claimed to do this, but they
used a disk drive with a motorized load/eject
and would not eject a disk unless you did an
unmount. You could force an eject, but then you
got corruption.
It is a basic fact of life in a high performance
file system that data is not written when you
write to the file, it is written when something
occurs to flush it to the media. I believe DOS
wrote immediately and thus got around the problem.
But floppies are slow, so you take a big performance
hit for working directly with the media rather than
a buffer.
If you take an unsynced diskette out, it may not
only have blocks not written, it may have the
entire directory in a bad state.
Even NeXT, which I alluded to above, never got this
right. The biggest problem I ever found in the
system was the automounting/unmounting of removable
media. It could get utterly confused to the point
of requiring a reboot to unconfuse the system; or
at worst lock the system up so badly that you had to
pull the plug.
I have a very low level of faith that systems like
this can be made to work. Even if you have multiple
disks and keep track of which is in, the disks will
all be effectively corrupted unless loaded and synced
before rebooting the computer or using the diskette
elsewhere.
------------------------------------------------------
Use Linux: A computer Dale Amon, CEO/MD
is a terrible thing Village Networking Ltd
to waste. Belfast, Northern Ireland
------------------------------------------------------
-
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 : Wed Feb 23 2000 - 21:00:33 EST