Linux-kernel mailing list archive 2000-07,: Re: Of removable devices

# Re: Of removable devices

Richard B. Johnson (root@chaos.analogic.com)
Wed, 16 Feb 2000 16:02:55 -0500 (EST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Jeff Garzik: "Re: [patch-2.3.36-p3] dd if=microcode of=/proc/driver/microcode"
- Previous message: Ian Peters: "Unable to load Creative ViBRA16X PnP with kernels 2.3.4[456]"
- In reply to: Khimenko Victor: "Re: Of removable devices"
- Next in thread: Khimenko Victor: "Re: Of removable devices"

On Wed, 16 Feb 2000, Khimenko Victor wrote:
[SNIPPED...]

>
> No. You misunderstood conception again.

I understand 'conception' perfectly.

> Idea is simple: user DO NOT NEED TO DO
> ANYTHING before floppy removal. But when program tries to write on removed
> floppy (even if there are other floppy inserted and even used) kernel will send
> message to notification daemon with request to put old floppy back. Process is
> stopped and all dirty buffers are kept in memory till floppy is changed back.
> When "right" floppy is inserted dirty buffers will be put on said floppy and
> process can continue. Without such protection ANY supermount implementations
> are just invitations to disaster. And THAT will require lots of changes in VFS.
>

DOS floppies have a serial number (32 bits). They can be identified.
This doesn't fix anything though.

Under Unix, we `mount` disk devices to make them accessible. You can not
mount another floppy without unmounting the previous one so you never
have the supposed problem of; "having another inserted and even used",
unless you are just writing to it raw, which in that case nothing will
protect you because you can write to the raw device even if it's the
correct one and it's mounted.

However, there is a button on most of the PC drives that 'allows' a user
to remove a mounted floppy.

Sun machines don't have any such button, so you can't do something that
you are not supposed to do without using a paper-clip. If you use a
paper-clip, you get worse than you asked for because on the Sun, an
access to a nonexistent floppy will panic the machine.

Under Linux, it's just:

Script started on Wed Feb 16 15:34:04 2000
# mount /dev/fd0 /mnt
# ls /mnt
command.com drvspace.bin io.sys msdos.sys
# cp xxx.c /mnt
#
# cp xxx.c /mnt
cp: cannot create regular file `/mnt/xxx.c': Read-only file system
# umount /mnt
# exit
exit

Script done on Wed Feb 16 15:35:27 2000

Upon such an error, the file-system is just turned into read-only.
Of course, if kernel error messages are being fed to your terminal,
the stuff you get on the screen looks far more serious.

The program I wrote will flush file-system buffers to the floppy so
that even if you remove it, the floppy contents are correct.

Suppose you invented a new kind of Unix where you didn't have to
mount file-systems to make them accessible, and you didn't have
to unmount them to update their contents before making then inaccessible.

You are just going to read the device to see if anything is there.
How would you let the kernel 'know' that the right one was installed
in the first place? Certainly you would have to send the kernel a
command that this with the 'right one'. So, you have just "mounted"
the file-system. You just told the kernel that this is the one you
want to use.

Now, suppose each file-system had a unique ID, like the floppy ID.
The kernel can then 'know' if the floppy has been removed by reading
the ID each time (when....). If you are going to re-read the physical
device every time you access the file-system, you now have a
paper-tape for speed.

Instead, the kernel treats the floppy just like the other VFS devices.
It does most of its I/O to buffers in memory. The only time the buffers
are guaranteed to be written to the physical media is when it's
un-mounted.

Floppies are considered cheap throw-away items. You don't add non-trivial
exception handlers to the kernel to save 15 cents now and then.

Cheers,
Dick Johnson

Penguin : Linux version 2.3.41 on an i686 machine (800.63 BogoMips).

-
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/

- Next message: Jeff Garzik: "Re: [patch-2.3.36-p3] dd if=microcode of=/proc/driver/microcode"
- Previous message: Ian Peters: "Unable to load Creative ViBRA16X PnP with kernels 2.3.4[456]"
- In reply to: Khimenko Victor: "Re: Of removable devices"
- Next in thread: Khimenko Victor: "Re: Of removable devices"