From owner-freebsd-current Mon May 31 10:33:14 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 1F39D14F62 for ; Mon, 31 May 1999 10:33:12 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA76108; Mon, 31 May 1999 10:32:10 -0700 (PDT) (envelope-from dillon) Date: Mon, 31 May 1999 10:32:10 -0700 (PDT) From: Matthew Dillon Message-Id: <199905311732.KAA76108@apollo.backplane.com> To: Ustimenko Semen Cc: Bruce Evans , freebsd-current@FreeBSD.ORG Subject: Re: How can i fail buf? References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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. Generally the problem is that when a write fails, the buffer is not invalid - it still contains perfectly valid data. We need a more sophisticated mechanism to deal with I/O errors. Throwing away the buffer (at least initially) is *not* the correct solution. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message