Re: Floppy handling

From: Jesse Pollard (pollard@tomcat.admin.navo.hpc.mil)
Date: Tue Jun 13 2000 - 08:12:08 EST


"Tim R." <omarvo@hotmail.com>
> You all are being silly.
> Copying the whole disk is painfully slow.
> And i've heard of automounters that check the drive every x secs to see if
> there's a disk in it.
>
> First things first, we shouldn't give a fsck if the user puts in a disk or
> not, atleast not when he puts it in.
> When we care is when he tries to access the mount point, then we check for a
> disk and mount if there is one.
> Polling the disk every x secs is just stupid, we have no need to mount until
> he tries to access it anyway.

Yes it is, but the only way to know if a user puts a floppy in is by testing
it.

> The only good way to handle removed it is like the macitoshes do, make you
> click a button or type a command to eject it.

You forgot that PC floppies can't prevent the user from ejecting the floppy
anyway.

> Other than that, before doing any writes we probably should check to make
> sure we have the same disk, and bitch
> otherswise.

And how do you propose doing that, since the floppy doesn't have an enforcable
label? and the labels that are there get duplicated a lot.

> Maybe we need a mount option that causes the fs's to verify
> they still have the same disk before writting?

You can't determine if it is the same disk.

> The hard part is figuring out how to complain. You almost need a special
> way for writes to return errors on this sort of
> thing. I really don't see what's so hard about saying "Click this button
> before taking the disk out so that, unlike windows,
> you know its really done saving your important file."

1 The user can take the disk out at any time, so you won't be able to prevent
  it.
2 which user? X or command line? Is he authorized?

> This works really well when there isn't an eject button or it can be locked
> like cd-roms =)

It works better.

> One thing you could do is have some sort of nullfs or a writethru ramfs
> union mounted over the floppy where you write the
> file if the disk is removed, so the data isn't lost, and prompt the user to
> put that damn disk back in.

That would allow for eliminating the dd, but what about the possiblility of
overflowing the floppy?

> Or, we could just make sure the light stays on the whole time until we
> umount it. That way the user would remember to
> click the button.

The light stays on only while the disk is active. (checking the disk
every second will do that ...)

The overall floppy hardware design is very very poor. There are no assurances
that allow an OS to determine what is happening to it, or allow the OS
to limit what is done to it (interlocks do not exist).

I like the idea of the union mount, but combined with something that will
limit the size of the resulting file system. Ramfs is not a good idea since
those could run the system OOM easily (does depend on the real capacity of the
system though...).

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

-
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:11 EST