Date: Tue, 18 Dec 2007 03:36:24 -0800 From: soralx@cydem.org To: freebsd-hackers@freebsd.org Subject: Re: Stale mount on disconnected device: how to delete it? Message-ID: <20071218033624.2b71bdb5@soralx> In-Reply-To: <20071218055201.GB51227@ace.netcins.ceid.upatras.gr> References: <1197889622.4766585626a92@webmail.rawbw.com> <1197916368.4766c0d0db6a8@webmail.rawbw.com> <20071218001355.GA40289@marvin.blogreen.org> <20071218055201.GB51227@ace.netcins.ceid.upatras.gr>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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 <ntarmos@ceid.upatras.gr> [SorAlx] ridin' VS1400
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071218033624.2b71bdb5>