From owner-freebsd-hackers Sun Jan 12 10:42:27 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA10281 for hackers-outgoing; Sun, 12 Jan 1997 10:42:27 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id KAA10276 for ; Sun, 12 Jan 1997 10:42:24 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA25800; Sun, 12 Jan 1997 11:30:53 -0700 From: Terry Lambert Message-Id: <199701121830.LAA25800@phaeton.artisoft.com> Subject: Re: mount -o async on a news servre To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 12 Jan 1997 11:30:52 -0700 (MST) Cc: freebsd-hackers@freebsd.org In-Reply-To: from "J Wunsch" at Jan 11, 97 11:52:41 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > 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.