Date: Thu, 19 Jul 2007 12:21:35 +0300 From: "Dennis Melentyev" <dennis.melentyev@gmail.com> To: "Momchil Ivanov" <idiotbg@gmail.com> Cc: "\[LoN\]Kamikaze" <LoN_Kamikaze@gmx.de>, freebsd-stable@freebsd.org, Norberto Meijome <freebsd@meijome.net>, olli@lurza.secnetix.de, josh@tcbug.org Subject: Re: removing external usb hdd without unmounting causes reboot? Message-ID: <b84edfa10707190221t60b98395pc35763017325b4c4@mail.gmail.com> In-Reply-To: <200707190943.55428.idiotbg@gmail.com> References: <200707181703.07480.idiotbg@gmail.com> <20070719130252.6880b967@localhost> <469F101C.5060906@gmx.de> <200707190943.55428.idiotbg@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi All! 2007/7/19, Momchil Ivanov <idiotbg@gmail.com>: > On Thursday 19 July 2007 09:17:48 [LoN]Kamikaze wrote: > > Norberto Meijome wrote: > > > On Wed, 18 Jul 2007 17:41:04 +0200 (CEST) > > > > > > Oliver Fromme <olli@lurza.secnetix.de> wrote: > > >> another work-around > > >> is to use the auto mounter daemon (amd(8)). It umounts > > >> file systems automatically that are not in use. > > >> Another nice feature of amd(8) is that you don't have > > >> to mount the file system either -- Simply plug the USB > > >> stick in, then access it, and amd(8) will automatically > > >> mount it for you. > > > > > > Now, something I dont understand - amd runs > > > at user level, and it mounts filesystems, and nothing dies when the > > > filesystems go away (other than the obvious cases for the applications > > > trying to write to the FS in question). Doesn't amd , at some point , > > > have to tell the kernel 'please mount this filesystem' here or there? > > > Isn't the kernel STILL involved in all this? and why doesnt the kernel > > > panic when the FS goes away? > > > > The trick is that amd unmounts the device after a couple of seconds, so > > when someone accidentally removes a usb drive, it doesn't really matter. > > Amd will simply fail to mount it on the next access. If you remove the > > device during or shortly after accessing it, it still will panic the > > system. > > What is then the reason for the kernel not being able to unmount a filesystem > whose provider is no longer present? What in the process of unmounting denies > unmounting a filesystem whose provider is no longer available? Why can the > kernel not just inform all programs that files have to be closed and are > unaccessible any more, then consider the fs as unmounted and remove any bits > of it left in the VM. Why can kernel not just ignore interruped/pending > writes to that fs, drop the data, return an error to the program that > initiated the write and just go on. For me, the most expected behaviour of API is the same as socket one: In case recv/send fails (socket peer gone, router in-the-middle is died, excavator came across the cables, etc) I just get a timeout (for the first time), then (once remote socket is considered closed) just return with -1 and appropriate errno set. Since every (not braindamaged) program expect possible disk failures, everyone checks for return/errno. It should be extremely safe to just supply notify userland with "-1/errno" to handle over the error case at application level. Since I do understand the complexity and impact of VM/[V]FS code, I'd rather vote for funding an external project on better VM/VFS separation and improvement. Later, this project codebase must be merged into the CURRENT, tested and go "STABLE" the usual way. The famous "Floppy" issue of FreeBSD MUST go away, it's just a shame and long standing base for unpleasant rumor/jokes. Could it be the good task for FreeBSD Foundation or what ever other investor? Sorry for adding just 0.02UAH instead of real $20-30-50 of personal money to the fund's account. If there is such a fund for this particular problem, I'll vote with money instead of bytes. I believe, there will be a lot more people willing to do the same to gain enough funding. -- Dennis Melentyev
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b84edfa10707190221t60b98395pc35763017325b4c4>