> >nil. Actually, accessing the disk while it is removed will yield the
> >affected floppy unit useless and a D state process.
>
> The type of the mounted filesystem may also be important. When a
> disk is removed when mounted, the floppy driver has not many choices
> except to report to the upper layers (filesystem code) that there is a
> problem. Some filesystems (minix ?) seem to not handle this situation
> gracefully, and panic if they get any errors. Others (ext2 ?) do it
> the correct way, and just remount themselves readonly if a "fatal"
> error occurs. This prevents further corruption to the disk, but still
> allows the user to work with other parts of the system.
>
> For this reason, it would be useful if people experiencing these
> kinds of bugs would prominently mention the name of the _filesystem_
> that was used in the "Subject" line of the message, so as to attract
> the interest of the right people.
OK, done. I experimented with three filesystems (minix, ms-dos and ext2)
to see what they did. This is system tested under:
Linux slackware 2.0.23 #2 Wed Oct 23 16:38:14 ADT 1996 i586
Minix and ms-dos gave kernel panics. The directory information given by
ls after the panic was incorrect (it seemed to show the initial state of
the directory), don't know why. Attempts to write to these filesystems
after the panic just gave more panics. The filesystems could be
umounted, freeing the device.
The ext2 filesystem, however, caused a panic and decided to change to
read-only mode. This sounds fine, but now accessing the device results
in D state processes. Attempting to umount the disk results in a hung D
state process. The floppy unit is useless.
While I am glad the kernel no longer Oopses on this floppy problem, the
ext2 fs seems to need a bit of work to get it right.
> The problem is actually deeper than that: even if the drive notified
> the kernel when (i.e. after) removing the disk, the kernel could not
> do anything about it, as at that time the disk is no longer there to
> write any dirty buffers out that could be there.
I don't see a problem if it could notify the operator to return the
correct disk, and if the correct disk can be identified. Alternatively,
discarding the buffers might be a good idea if a disk went away due to
power failure or being removed in the middle of a write, for example, since
the media is probably not in a very organized state anymore.
> using synchronous mounts. Synchronous mounts do not buffer data, and
> thus limit the damage done by unexpected disk removals. The downside
> is that they are far slower than normal (i.e. asynchronous) mounts.
Actually, I lost bdflush for awhile, and all the writes to the floppy
seemed to be synchronous. I downloaded a text page via 14k4 modem to
floppy with the floppy churning away seemingly without a pause or loss of
characters from the modem. I am reasonably impressed with the floppy
interrupt handling.
Seasons Greetings to all.
-- William Burrow -- Fredericton Area Network, New Brunswick, Canada Copyright 1996 William Burrow Canada's federal regulator says it may regulate content on the Internet to provide for more Canadian content. (Ottawa Citizen 15 Nov 96 D15)