Date: Mon, 31 May 1999 19:30:08 +0700 (NSS) From: Ustimenko Semen <semen@iclub.nsu.ru> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-current@FreeBSD.ORG Subject: Re: How can i fail buf? Message-ID: <Pine.BSF.4.05.9905311917460.57028-100000@iclub.nsu.ru> In-Reply-To: <199905310421.OAA27787@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 31 May 1999, Bruce Evans wrote: > 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? :-) > I use the following variant of the patch in PR 11697: > > [patch skipped] > Will it ever included in current? > 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. 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. 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?Pine.BSF.4.05.9905311917460.57028-100000>