Date: Thu, 3 Jun 1999 02:13:16 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, semen@iclub.nsu.ru Cc: freebsd-current@FreeBSD.ORG Subject: Re: How can i fail buf? Message-ID: <199906021613.CAA06534@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> This isn't solved. It was less serious before rev.1.196 of vfs_bio.c >> when B_ERROR buffers were discarded insead of re-dirtied in the above >> code fragment. See also PR 11697, and about 20 PRs reporting problems >> with i/o errors and EOF "errors" (ENOSPC/EINVAL) for (mis)using buffered >> devices (especially fd0). >> > >Why they have done so? B_ERROR have to mean unrecoverable >error, doesn't it? Or we need something like > >Writing to ... at ... failed. >(A)bort, (R)etry, (I)gnore? > >:-) Even that has some advantages over our current and previous handling :-(. >> I use the following variant of the patch in PR 11697: >> >> [patch skipped] >> > >Will it ever included in current? I'm waiting for the committer of vfs_bio.c rev.1.196 to fix it. >> This fixes the primary problem in all cases except the most interesting one: >> for real i/o errors. It doesn't touch the secondary problem that most >> VOP_FSYNC() routines don't try hard enough to write all dirty buffers in >> the MNT_WAIT case, so vinvalbuf() may panic. > >As i see, we need some B_FATAL flag, that will signal brelse to >do not redirty buf, for example to set when media in fd >was changed. Still not quite right. I debugged this with write protected floppies. The driver currently retries a lot and spews a message for each failure. The best handling is close to what is provided by Abort/Retry/Fail (don't do anything until the disk is changed...). >About F_SYNC: usually they do, they try very hard to free >dirty queue, look at msdosfs_vnops.c, and 'man VOP_FSYNC' >pseudocode. Pseudocode even loops infinitly if there is a >not writable buf. I overestimated the extent of this problem. It seems to be limited to ffs_fsync(), which gives up after a couple of passes. I think the fatal case is only reached for unmount(). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906021613.CAA06534>