Date: Sat, 11 Jan 1997 12:52:34 -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: <199701111952.MAA24055@phaeton.artisoft.com> In-Reply-To: <Mutt.19970111123319.j@uriah.heep.sax.de> from "J Wunsch" at Jan 11, 97 12:33:19 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Every 30 seconds by default, but its tunable with sysctl.. > > > > Due to two cooperating coding errors, setting this value higher > > will increase the time between when you unmount removable media > > and the time you can successfully eject the media (in case you > > were wondering about the delay on ejecting clean JAZ disks...). > > Huh? You mean, after a successful umount, i could not eject a > removable medium? I've never seen this, and i'm occasionally using a > MO drive. Not only that i could remove it after umounting, my `od' > driver even runs with the option to spin down the cartridge after > closing, so i would `hear' if the drive were still open. > > Please, quote the coding errors, instead of only throwing claims. The buffers for the device are not decommitted until the next vclean run, since the freed vnodes with buffers attached are still in the cache. Perhaps "coding errors" was too strong; "antiquated design decisions which did not consider the maximum possible number of future usages to which the code might later be put" is probably more apt. Maybe it could be most simply stated as "there are two places where the code authors failed to look into the future". 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?199701111952.MAA24055>