From owner-freebsd-hackers Sun Jan 12 13:40:34 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA24501 for hackers-outgoing; Sun, 12 Jan 1997 13:40:34 -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 NAA24496 for ; Sun, 12 Jan 1997 13:40:31 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA26338; Sun, 12 Jan 1997 14:28:50 -0700 From: Terry Lambert Message-Id: <199701122128.OAA26338@phaeton.artisoft.com> Subject: Re: mount -o async on a news servre To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 12 Jan 1997 14:28:50 -0700 (MST) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: from "J Wunsch" at Jan 12, 97 09:40:06 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 > > > Otherwise, everything works as expected. You can eject (or spin down) > > > the medium as soon as the umount completes. > > > The drive light does not go active until updated fires the writes; > > Then this must be TerryBSD. :-) In FreeBSD, umount(2) triggers the > buffer write (as David has explained you from a theoretical point of > view, and i tried to prove you from my own experience with my MO > drive). When I close a file, I schedule dirty buffers to be written. But I do not dissociate the inode from the vnode until that write has taken place because buffers are indexed by vnode/offset, not by device offset. If I do a bunch of writes, a close, and then a umount, there is a potential delay of the update time between the time the dirty buffer is written and the time it has successfully been reclaimed. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.