Date: Wed, 2 May 2001 01:20:03 -0700 (PDT) From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/25992: System hangs when read-only floppy has been mounted Message-ID: <200105020820.f428K3H97290@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/25992; it has been noted by GNATS.
From: Bruce Evans <bde@zeta.org.au>
To: Dima Dorfman <dima@unixfreak.org>
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: kern/25992: System hangs when read-only floppy has been mounted
Date: Wed, 2 May 2001 18:15:17 +1000 (EST)
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
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200105020820.f428K3H97290>