From owner-freebsd-hackers  Sun Jan 12 11:21:48 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id LAA12127
          for hackers-outgoing; Sun, 12 Jan 1997 11:21:48 -0800 (PST)
Received: from root.com (implode.root.com [198.145.90.17])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id LAA12120
          for <freebsd-hackers@freebsd.org>; Sun, 12 Jan 1997 11:21:45 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id LAA25941; Sun, 12 Jan 1997 11:17:03 -0800 (PST)
Message-Id: <199701121917.LAA25941@root.com>
X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol
To: Terry Lambert <terry@lambert.org>
cc: joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@freebsd.org
Subject: Re: mount -o async on a news servre 
In-reply-to: Your message of "Sun, 12 Jan 1997 11:30:52 MST."
             <199701121830.LAA25800@phaeton.artisoft.com> 
From: David Greenman <dg@root.com>
Reply-To: dg@root.com
Date: Sun, 12 Jan 1997 11:17:03 -0800
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>> 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.

   Terry is simply wrong about what happens. All dirty buffers are written out
and invalidated/reclaimed when the umount is called and all other buffers are
invalidated/reclaimed. When all buffers are have been reclaimed, all vnodes
and VM objects (and all other resources associated with the mounted filesystem)
are invalidated and reclaimed. Umount doesn't return until this is completed,
but the total delay is very short (less than 1 second). Any delay prior to
'eject' is not due to buffers being stuck or waits for the update process to
run or anything of the sort.

-DG

David Greenman
Core-team/Principal Architect, The FreeBSD Project