>1. What good does the light do to you if you are x miles away telneting into
>the videoless, keyboardless, consoleless box.
It stops other people that wish to use the floppy station.
"oooh, it's busy!" There are universities that save money
by not purchasing a floppy drive for every machine, and
businesses that do the same for security reasons.
Users that occationally need to use a floppy use the one
machine that have one. But they need the file
on their own machine, so they use the network.
>2. I am not sure but I do not think the light is program configurable you
>actually have to be accessing the disk to do this. Annoying ase it makes
You need to leve the motor running. No need to access the disk.
>noise and slows the system down though Linux doesn't slow down as much as
There is no slowdown *at all*. There is no cpu needed to leave the
running. Actually less, as you don't even take the trouble to turn it
Windows users seems to believe the floppy drive actually need
cpu to work - I wonder what ms does wrong. The floppy has such low
bandwith (and use DMA like a modern harddisk too) so it use little cpu,
substantially *less* than harddisk or anything else.
A machine running linux (or os2 or about anything non-ms) seems to
have *no* noticeable impact on busy applications when the floppy
is being used. This was the case with the 386 33MHz, and is still
the case (no surprise) with todays faster machines.
>3. It is a common error indicator to have a floppy light that doesn't go
>out. Malfunctioning floppy, floppy cable reversed, floppy stuck, etc.
It won't be on forever. It'll go out as soon as ejecting won't
destroy the filesystem.
>4. As for syncing if you do all writes to the floppy ASAP without disturbing
>any filesystem mount/status flags etc there is not need to inplement a
>syncing procedure. Plus the behavior follows that which users have become
You don't want to do it ASAP, a reasonable timeout is *great* for
throughput. But then you need the light informing users that
ejecting now is a bad idea. Syncing is good as the current cache
can hold back blocks for a long time, greatly increasing the
risk of an impatient user ejecting. "My cp command finished, and the
turned off. Why did it mess up on eject? what is this umount thingy?"
>> Better hardware (with locked eject) is nice, this is for those
>> with plain pc floppies.
>? So are all the ideas pitched so far.
No, some people suggest "lock the drive". Doable on some cdroms
and mac floppies, but not a general solution.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:16 EST