Date: Sun, 12 Jan 1997 11:30:52 -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: <199701121830.LAA25800@phaeton.artisoft.com> In-Reply-To: <Mutt.19970111235241.j@uriah.heep.sax.de> from "J Wunsch" at Jan 11, 97 11:52:41 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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. > > > The buffers for the device are not decommitted until the next vclean > > run, ... > > Perhaps they are not _guaranteed_ to be decommitted until the next > vclean run? No, i don't think so. umount(8) waits until all buffers > are clear, which often can take a tremendous amount of time on a MO > medium. Once umount(8) returns, the medium spins down immediately, > which basically means odclose() has been called. This proves your > theory wrong. 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. Of course, you can't do anything about that, because theres no way to force the buffers which have been technically thrown away, but not yet reclaimed. Yes, I know this invokes yet another "theory"... the one that says people will probably want to remove removable media when they do an explicit unmount of said media, and the "corrolary" that says that the reason for doing this might be to insert different media in the same device. Naw, no one would *ever* want to do that.... 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?199701121830.LAA25800>