From owner-freebsd-fs@FreeBSD.ORG Thu Feb 22 15:39:51 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6C3A316A400 for ; Thu, 22 Feb 2007 15:39:51 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id 3BF4813C474 for ; Thu, 22 Feb 2007 15:39:51 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l1MFcf8f072490; Thu, 22 Feb 2007 09:38:42 -0600 (CST) (envelope-from anderson@freebsd.org) Message-ID: <45DDB906.1070405@freebsd.org> Date: Thu, 22 Feb 2007 09:38:46 -0600 From: Eric Anderson User-Agent: Thunderbird 1.5.0.9 (X11/20070204) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bj=F6rn_K=F6nig?= References: <4d3557900702210155n2f57761fl6b8b4df500a1cf77@mail.gmail.com> <45DC59C0.8080206@freebsd.org> <45DDAE70.8010508@alpha-tierchen.de> In-Reply-To: <45DDAE70.8010508@alpha-tierchen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.88.4/2628/Thu Feb 22 05:31:25 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=8.0 tests=BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: freebsd-fs@freebsd.org Subject: Re: The patch delete no umount eject flash disk freebsd panic X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 15:39:51 -0000 On 02/22/07 08:53, Björn König wrote: > Eric Anderson schrieb: > >> So what happens when you have a regular drive fail then? Or yank a SATA >> or other drive out from under the OS? >> >> This patch seems awfully dangerous to me.. > > I don't want to disagree. This is dangerous. Seriously, I have another > thought: is it less dangerous to risk data loss or corruption of other > file systems that are not affected just because we killed the whole > system immediately? > > I had this problem several times: device removed and access to one of > its file systems causes the death of the machine. For example: > > - insert a disk into floppy disk drive > - mount its file system > - remove floppy disk (oops!) > - insert it again (quickly, before anything notice) > - umount the file system > => kernel panic > > The result is that other well running file systems on this machine > became corrupt or inconsistent. This issue definitively needs a > solution. I understand if you don't want to ignore and override the > disappearance of a file system, but in this case we probably either need > a kind of "soft panic" that tries to unmount other file systems before > death blow, a safe way to force unmounting a broken file system without > kernel panic explicitely or a configurable case differentiation. I agree that other file systems should not be messed with. I suppose instead of panicking another option is the remove the mount point, blast anything in cache for it, and then kill any processes touching it? How would one deal with daemons like mountd, and nfsd though? This would be a good thing for servers too, since a missing file system would hopefully not kill everything. Maybe someone with more locking/file system/geom knowledge could provide some input here.. Eric