Den 23-Feb-00 13:10:50 skrev Dale Amon fĝlgende om "Re: Of Removable Media":
> 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.
I've been listening with great interest too since I've used Amigas for
something like 11 years now, a system where floppies are of the standard PC
type, i.e. no door locking possible.
There seems to be three different issues raised in the discussion so
far:
1) The hardware that can't lock the drive door. All this means is that
existing data on the media can be corrupted if the user ejects the media
while it is written to. There is nothing you can do about this, except to
educate the user and live with it.
2) Handling the case of mounted media which is ejected (and possibly
reinserted) during inactivity. I don't understand why that doesn't just
work. There is no reason why it shouldn't. It always has worked on the
Amiga (since its birth in 1985!), of course it should work on a Linux
system too.
3) Prompting the user to reinsert media. The question here is if and how to
prompt the user. It may not be possible, too difficult to figure out how or
even turned off, in which case simply assume the user chose "Cancel" and
return the appropriate error code. This has also worked fine on the Amiga
for 15 years. AmigaOS lets each process provide the OS with hints as to
where to prompt the user. Each processes can also turn off the prompts.
4) Handling the case of multiple media, possibly with open files on them.
>From what knowledge I have about Linux, I say: Forget it. Linux was never
designed to handle removable media (remarkable for such a late OS design,
btw.), and it could be quite a lot of work to add such support. But it can
be done as the Amiga proves.
> 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.
There is no need for a performance hit here. Simply start writing
(asyncronously, in case it wasn't clear) dirty buffers during inactivity,
and before turning off the LED on the drive. Most (not all) drives I've
seen light the LED when the motor is turned on.
> 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.
That's not a problem, the file system just needs to leave the disk in a
consistent state. This is considered to be a standard feature these days,
AFAIK even ext2fs is getting it (in the form of ext3fs) and at least one
other such file system is available for linux already, with more to come.
[ It doesn't work on NeXT, so nobody else could possibly have gotten it
right either ]
Absolutely not. See the Amiga as an example where it works, and always
has.
Regards,
/ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻTŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\
| Rask Ingemann Lambertsen | E-mail: mailto:rask@kampsax.dtu.dk |
| Please do NOT Cc: to me or the | WWW: http://www.gbar.dtu.dk/~c948374/ |
| mailing list. I am on the list.| "ThrustMe" on XPilot, ARCnet and IRC |
| To err is human, but to really mess things up you need a computer. |
-
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 : Tue Mar 07 2000 - 21:00:16 EST