From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 18 11:36:28 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02DBB16A419 for ; Tue, 18 Dec 2007 11:36:28 +0000 (UTC) (envelope-from soralx@cydem.org) Received: from pd2mo3so.prod.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by mx1.freebsd.org (Postfix) with ESMTP id C7EBE13C469 for ; Tue, 18 Dec 2007 11:36:27 +0000 (UTC) (envelope-from soralx@cydem.org) Received: from pd3mr1so.prod.shaw.ca (pd3mr1so-qfe3.prod.shaw.ca [10.0.141.177]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0JT8007H3TKRK540@l-daemon> for freebsd-hackers@freebsd.org; Tue, 18 Dec 2007 04:36:27 -0700 (MST) Received: from pn2ml2so.prod.shaw.ca ([10.0.121.146]) by pd3mr1so.prod.shaw.ca (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTP id <0JT8004FYTKQNBF0@pd3mr1so.prod.shaw.ca> for freebsd-hackers@freebsd.org; Tue, 18 Dec 2007 04:36:27 -0700 (MST) Received: from soralx ([24.87.3.133]) by l-daemon (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTP id <0JT8000RXTKPJW10@l-daemon> for freebsd-hackers@freebsd.org; Tue, 18 Dec 2007 04:36:26 -0700 (MST) Date: Tue, 18 Dec 2007 03:36:24 -0800 From: soralx@cydem.org In-reply-to: <20071218055201.GB51227@ace.netcins.ceid.upatras.gr> To: freebsd-hackers@freebsd.org Message-id: <20071218033624.2b71bdb5@soralx> MIME-version: 1.0 X-Mailer: Claws Mail 3.0.2 (GTK+ 2.10.14; i386-portbld-freebsd6.2) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit References: <1197889622.4766585626a92@webmail.rawbw.com> <1197916368.4766c0d0db6a8@webmail.rawbw.com> <20071218001355.GA40289@marvin.blogreen.org> <20071218055201.GB51227@ace.netcins.ceid.upatras.gr> Subject: Re: Stale mount on disconnected device: how to delete it? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2007 11:36:28 -0000 > > The problem is that the detach event can be caught only too late to > > unmount the device properly. How may it be possible to sync a disk > > ``as soon as it is detached'' (that is when it is not physically > > connected to the computer anymore)? Mounting the disk read-only may > > be a workaround, just as not caching writes (default behaviour of > > some versions of Windows) and syncing the disk all the time, but > > this is not as reliable as the mount system provided by Unix and > > Unix like operating systems. > > > > AFAICR, this is the sole weakness of the FreeBSD operating system I > > know :) And since it is, according to me, an operator error, the > > best we can do is to use the system as it was designed for ;) > > Off the top of my head, what is wrong/hard with just logging a device > failure, discarding all remaining cached operations, and unmounting > the fs when a disk device goes missing? I understand that this is not > a viable solution for critical filesystems, but I can see nothing > wrong with this approach for removable devices and/or non-critical > fs's. I was wondering that myself. The possibility of losing data (after some timeout, of course) sure as heck beats recovering from the annoying panicks when something happens with the filesystem's underlying device. And who said those panicks are no problem for production systems? My workstation is a "production system", and it is very hard to recover from reboots in general, and crashes in particular. Unfortunately, they do happen fairly often, usually caused by USB-related stuff (FreeBSD's USB stack is _the_ worst I've seen lately -- I take it that the stack's favorite hobby is panicking the kernel with unrivaled efficiency), sometimes by ATA/ATAPI/SATA (interestingly, SCSI code is quite stable), someimes by something obscure (e.g., just exiting qbittorrent kills the kernel -- NFS woes maybe? just an example). Hot-swapping with some ATA and SCSI drivers is impossible, too (result in panics). I hope you don't mind me, an ol' whiner here, too much, but I really had to say that FreeBSD used to be far more stable. So it seems the trade-off "stability->features" could not be avoided... > Comment: Nikos Ntarmos [SorAlx] ridin' VS1400