Date: Sun, 12 Jan 1997 13:00:59 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: mount -o async on a news servre Message-ID: <199701122000.NAA26148@phaeton.artisoft.com> In-Reply-To: <Mutt.19970112200006.j@uriah.heep.sax.de> from "J Wunsch" at Jan 12, 97 08:00:06 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Except that it's unreasonable to delay the unmount for vclean instead > > of explicitly committing the buffers, and my "theory" was predicated > > on the delay between when you issue "umount /dev/xxx; eject /dev/xxx" > > and the actual eject. > > You're suggesting that the umount should _not_ wait now? :-) No. I am suggesting that it should trigger the action rather than delaying until the action has occurred of its own accord. We have an interactive user event (the "umount" request), and we are capable of servicing it, yet we delay servicing it for an operation which we could also trigger as a result of the event, but which we do not. What has happened is that, for no good reason, the event and the response to the event have been time decoupled. > Otherwise, everything works as expected. You can eject (or spin down) > the medium as soon as the umount completes. By `completes' i mean it > returns to the shell. From my experience, it does _not_ wait until > the update daemon comes along next time. > > If the umount takes a long time in your case (as it does much more > noticable in the MO case), that's because you've got too many dirty > buffers. Of course you can also wait first for the update daemon to > come by, so afterwards the umount will complete instantly. :) Oh come now! I've written too much to my drive?!?! What's the point of having a honking big drive if I'm never allowed to write to the thing more than a little bit between mounts? Foo! The drive light does not go active until updated fires the writes; I can intentionally time this so that the umount request is submitted only after the updated competes and goes back to sleep. Consider that I might use the JAZ drive for the reason IOmega states they sell it: to back up my system. Therefore my "umount" follows immediately on the heels of my last "close". At best, it's an average of 50% of the update period for the machine (which for my box is 120 seconds). Yes, I know my update value is tuned large... the update operation should not be predicated on a timer in the umount case, since we have a umount "event" in the kernel to precipitate the update on behalf of the user. *CLEARLY*, we have a human being waiting on the other side of the umount command, either explicitly, or implicitly (ie: waiting for umount while waiting for shutdown). It is bad form, indeed, to make the human wait, arbitrarily. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701122000.NAA26148>