From owner-freebsd-hackers Sat Oct 19 23:50: 5 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 29B1C37B401; Sat, 19 Oct 2002 23:50:04 -0700 (PDT) Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2EA843EA9; Sat, 19 Oct 2002 23:50:03 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0064.cvx40-bradley.dialup.earthlink.net ([216.244.42.64] helo=mindspring.com) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1839uR-0006g8-00; Sat, 19 Oct 2002 23:50:00 -0700 Message-ID: <3DB251D0.495C6A44@mindspring.com> Date: Sat, 19 Oct 2002 23:48:48 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: David Schultz , Poul-Henning Kamp , Maxim Sobolev , hackers@FreeBSD.ORG Subject: Re: Patch to allow a driver to report unrecoverable write errors to the buf layer References: <3DB048B5.21097613@FreeBSD.org> <28472.1035014051@critter.freebsd.dk> <20021020043706.GA23972@HAL9000.homeunix.com> <200210200457.g9K4vbAE030661@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon wrote: > :filesystem corruption because the vnode layer would be unaware > :that some buffers had been dropped. How hard would it be to fix this? > > Extremely difficult, which is why this is all fantasy and no action. > By the time the filesystem layer gets the notification there is > insufficient information to unwind the original operation(s) without > a huge amount of work. A bitmap write failed? Great! Find the > file that the related bitmap blocks are related to. Good luck! And > that is just one case out of dozens that would require a sophisticated > solution. It might be possible via softupdates, but I shudder at the > level of complexity of code required to support such a beast. Not to > mention the fact that pulling a floppy out a bad time could destroy > far more data then whatever pending write operations might have failed. > It's a waste of time. This really depends. Operations which are queued without the results being reaped before returning to user space doesn't necessarily mean that the results shouldn't end up going to the layer that originated the request. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message