Bug 25992
| Summary: | System hangs when read-only floppy has been mounted | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Rashid N. Achilov <shelton> |
| Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 4.2-STABLE | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Rashid N. Achilov
2001-03-22 14:40:02 UTC
"Rashid N. Achilov" <shelton@sentry.granch.com> writes: > > >Number: 25992 > >Category: kern > >Synopsis: System hangs when read-only floppy has been mounted > >Description: > > When read-only floppy has been mounted and start read from it, system > hangs quickly. This tremendous bug exist for ages, I periodically collided > with it from time to time... Are you mounting the floppy in read-only mode? I.e., are you doing `mount -r /dev/fd0 /mnt`? If you're not specifying the ``-r'', then I'm not surprised (I guess it should panic, not hang, though). If you are using ``-r'', then I can't reproduce this; I have a couple of computers with read-only floppies in them (for tripwire). Regards Dima Dorfman dima@unixfreak.org State Changed From-To: open->feedback Are you mounting the floppy in read-only mode? I.e., are you doing `mount -r /dev/fd0 /mnt`? If you're not specifying the ``-r'', then I'm not surprised (I guess it should panic, not hang, though). If you are using ``-r'', then I can't reproduce this; I have a couple of computers with read-only floppies in them (for tripwire). On Mon, Apr 30, 2001 at 05:51:45PM +0700, Rashid N. Achilov wrote:
> On Sunday 29 April 2001 09:26, dd@FreeBSD.ORG wrote:
> > Are you mounting the floppy in read-only mode? I.e., are you doing
> > `mount -r /dev/fd0 /mnt`? If you're not specifying the ``-r'', then
> > I'm not surprised (I guess it should panic, not hang, though). If you
> > are using ``-r'', then I can't reproduce this; I have a couple of
> > computers with read-only floppies in them (for tripwire).
>
> Hang or panic - which difference? One result - reboot :-(
Just as an aside. This problem has been with us forever. I can appreciate
that the real UNIX gurus do not hurry to fix this one since they always
know what to type and don't use floppies much anyway. (Neither do I.) But
this does not mean that in this situation we should panic (or hang for that
matter) Panics are for the situations where something is seriously wrong so
much so, that we decide to give up instead of marching on and possibly
producing non-sense results. But trying writing to a ro floppy should
simply fail. Why is there an assumption that a floopy is always writeable
unless indicated by -r otherwise? Would we try to write to (and
subsequently panic or hang) a CD-ROM as well? That would be a serious flaw
to me. While it is not the writing processes' business to know if that
media the FS is mounted from is writeable, but the underlying layers
certainly ought to know and act accordingly.
BTW the behaviour has changed over time... at a time it was just a hang.
Othertimes it was a panic. Sometimes it was even (gasp) a simple fail.
But this does not seem to be intentional, rather the by-product of other
changes...
Just like the fact that under 3.x one could mount mixed mode CDs on my
machine, but since ad(4) came along, this is not possible. But this is
unrelated, just grumping.
--
Regards:
Szilveszter ADAM
Szeged University
Szeged Hungary
Szilveszter Adam <sziszi@petra.hos.u-szeged.hu> writes: > On Mon, Apr 30, 2001 at 05:51:45PM +0700, Rashid N. Achilov wrote: > > On Sunday 29 April 2001 09:26, dd@FreeBSD.ORG wrote: > > > Are you mounting the floppy in read-only mode? I.e., are you doing > > > `mount -r /dev/fd0 /mnt`? If you're not specifying the ``-r'', then > > > I'm not surprised (I guess it should panic, not hang, though). If you > > > are using ``-r'', then I can't reproduce this; I have a couple of > > > computers with read-only floppies in them (for tripwire). > > > > Hang or panic - which difference? One result - reboot :-( The difference is that a panic is a whole lot easier to diagnose than a hang. > Just as an aside. This problem has been with us forever. I can appreciate I'm not sure which problem you're referring to. I just tried inserting a read-only floppy and mounting it read-write. I got a bunch of write failure errors when I tried to unmount it. No panic, no reboot. Lots of junk in the logs. Seems like correct behavior to me. I said panic above because I thought it'd be more logical behavior than a hang; spitting out write errors is even better. > that the real UNIX gurus do not hurry to fix this one since they always > know what to type and don't use floppies much anyway. (Neither do I.) But > this does not mean that in this situation we should panic (or hang for that > matter) Panics are for the situations where something is seriously wrong so > much so, that we decide to give up instead of marching on and possibly > producing non-sense results. But trying writing to a ro floppy should > simply fail. Why is there an assumption that a floopy is always writeable > unless indicated by -r otherwise? Would we try to write to (and Becuase it is mounted read-write. It's fair to assume that if you requested that a filesystem be mounted read-write, it can be written to. UFS (FFS?) will try to flush all buffers and update the superblock(s) or something like that (I probably got the details wrong) when you umount a filesystem mounted as read-write. As I said above, this causes lots of errors. On my computer (-current a few days old), it doesn't panic or hang. Dima Dorfman dima@unixfreak.org On Tue, 1 May 2001, Dima Dorfman wrote: > Szilveszter Adam <sziszi@petra.hos.u-szeged.hu> writes: > The difference is that a panic is a whole lot easier to diagnose than > a hang. > > > Just as an aside. This problem has been with us forever. I can appreciate More precisely, this bug (at least the panics and hangs for it) have been with us since: RCS file: /home/ncvs/src/sys/kern/vfs_bio.c,v Working file: vfs_bio.c head: 1.279 ... ---------------------------- revision 1.196 date: 1999/01/22 08:59:05; author: dg; state: Exp; lines: +5 -2 Don't throw away the buffer contents on a fatal write error; just mark the buffer as still being dirty. This isn't a perfect solution, but throwing away the buffer contents will often result in filesystem corruption and this solution will at least correctly deal with transient errors. Submitted by: Kirk McKusick <mckusick@mckusick.com> ---------------------------- Prior to this commit, write errors were handled by giving up on unwritable buffers. In particular, write errors for attempts to write to write protected media were fairly harmless. Immediately after this commit, write errors caused various panics and hangs, especially for block devices. Some of these problems have been fixed, mainly by unsupporting block devices, but I vinvalbuf() and thus unmount(2) still seems to be very broken. vinvalbuf() calls VOP_FSYNC() and then panics if VOP_FSYNC() didn't manage to sync everything, but VOP_FSYNC() can never sync unwritable buffers. It either loops forever trying to do so or returns with some buffers unsynced. > I'm not sure which problem you're referring to. I just tried > inserting a read-only floppy and mounting it read-write. I got a > bunch of write failure errors when I tried to unmount it. No panic, > no reboot. Lots of junk in the logs. Seems like correct behavior to > me. I said panic above because I thought it'd be more logical > behavior than a hang; spitting out write errors is even better. This may depend on the filesystem. For an empty ffs filesystem on a write-protected floppy under -current, I get endless retries and the problem can be recovered from by removing the write protection. This is because control doesn't get as far as the panicing vinvalbuf() in -current. dounmount() calls VOP_SYNC() and ffs's VOP_SYNC() (ffs_fsync()) has been fixed in -current to retry forever after VOP_FSYNC() fails (in the MNT_WAIT case). In RELENG_4, ffs_fsync() still gives up after an error fsyncing the vnode for the mounted-on device, so I think vinvalbuf() can be reached. Similarly for most non-ffs filesystems in -current. ffs_fsync() was fixed very recently in: RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_vfsops.c,v Working file: ffs_vfsops.c head: 1.152 ... ---------------------------- revision 1.150 date: 2001/04/25 08:11:18; author: mckusick; state: Exp; lines: +16 -7 ... Close a loophole that allowed unwritten blocks to be skipped when doing ffs_sync with a request to wait for all I/O activity to be completed. ---------------------------- > > that the real UNIX gurus do not hurry to fix this one since they always > > know what to type and don't use floppies much anyway. (Neither do I.) But > > this does not mean that in this situation we should panic (or hang for that > > matter) Panics are for the situations where something is seriously wrong so > > much so, that we decide to give up instead of marching on and possibly > > producing non-sense results. But trying writing to a ro floppy should > > simply fail. Why is there an assumption that a floopy is always writeable > > unless indicated by -r otherwise? Would we try to write to (and The kernel doesn't know whether the floppy is writable until it attempts to write to it. The ancient history of the bug includes a very broken attempt to fix this in the floppy driver by attempting to determine writability at open time. I consider this part of the bug unimportant. It might not be possible to determine writablity without trying the write. Especially for devices whose writability can change while they are open. When you do something stupid like mounting a write-protected floppies read-write, you should just get i/o errors, and these errors should be handled properly just like any other i/o errors on the device. Proper i/o error handling doesn't include panicing or spewing error messages for each retry like the floppy driver does :-). Bruce State Changed From-To: feedback->closed Duplicate for kern/10870 (and basically also for kern/4413) State Changed From-To: feedback->closed Duplicate for kern/10870 (and basically also for kern/4413) State Changed From-To: open->closed Duplicate for kern/10870 (and basically also for kern/4413) State Changed From-To: feedback->closed Duplicate for kern/10870 (and basically also for kern/4413) |
