From owner-freebsd-stable Thu Apr 11 23:36:57 2002 Delivered-To: freebsd-stable@freebsd.org Received: from segfault.kiev.ua (segfault.kiev.ua [193.193.193.4]) by hub.freebsd.org (Postfix) with ESMTP id 8FA8337B416; Thu, 11 Apr 2002 23:36:49 -0700 (PDT) Received: (from uucp@localhost) by segfault.kiev.ua (8) with UUCP id JOB53198; Fri, 12 Apr 2002 09:36:32 +0300 (EEST) (envelope-from netch@iv.nn.kiev.ua) Received: (from netch@localhost) by iv.nn.kiev.ua (8.11.6/8.11.6) id g3C6Ljr00320; Fri, 12 Apr 2002 09:21:45 +0300 (EEST) (envelope-from netch) Date: Fri, 12 Apr 2002 09:21:45 +0300 From: Valentin Nechayev To: Ian Dowse Cc: Coleman Kane , David Schultz , Bob Bishop , stable@FreeBSD.ORG Subject: Re: very old bug Message-ID: <20020412092145.A227@iv.nn.kiev.ua> References: <20020411100223.A64698@freebsd.org> <200204111604.aa64453@salmon.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200204111604.aa64453@salmon.maths.tcd.ie>; from iedowse@maths.tcd.ie on Thu, Apr 11, 2002 at 04:04:42PM +0100 X-42: On Organization: Dark side of coredump Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thu, Apr 11, 2002 at 16:04:42, iedowse (Ian Dowse) wrote about "Re: very old bug": > If an error occurs when the write is finally attempted, the buffer > cache is left in a predicament because it has no way to inform the > filesystem of the problem, and it can't just throw away the data > without risking serious filesystem corruption, and confusion within > the filesystem code. The two remaining options are to keep retrying > the write in the hope that it will eventually succeed, or panic. > > About the only other safe thing to do would be to completely > disassociate the failing device from the filesystem and throw away > any unwritten data. If the filesystem can handle the device going > away like this without panicking, then maybe the user might be able > to unmount it and contunue. Consider not floppy, but HDD, particularly one where root FS is placed.:( Panic or dissociation won't be good solution. Forever loop to write is somehow best, but it should give big delays for other processes work. But if FS carrier disappears, FS must be disassociated. But this is only pink dreams... /netch To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message