Date: Sun, 12 Jan 1997 11:17:03 -0800 From: David Greenman <dg@root.com> 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 Message-ID: <199701121917.LAA25941@root.com> In-Reply-To: Your message of "Sun, 12 Jan 1997 11:30:52 MST." <199701121830.LAA25800@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701121917.LAA25941>