From owner-freebsd-hackers Sun Jan 12 12:00:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA17641 for hackers-outgoing; Sun, 12 Jan 1997 12:00:11 -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 MAA17635 for ; Sun, 12 Jan 1997 12:00:07 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA26105; Sun, 12 Jan 1997 12:47:37 -0700 From: Terry Lambert Message-Id: <199701121947.MAA26105@phaeton.artisoft.com> Subject: Re: mount -o async on a news servre To: dg@root.com Date: Sun, 12 Jan 1997 12:47:36 -0700 (MST) Cc: terry@lambert.org, joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@freebsd.org In-Reply-To: <199701121917.LAA25941@root.com> from "David Greenman" at Jan 12, 97 11:17:03 am 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 > 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. I have had delays on the order of a minute when umounting my JAZ disk. I realize FreeBSD has problems handling JAZ drives that the other BSD's do not, like getting the media size right for a drive without meduia inserted instead of throwing an error into dmesg: (ncr0:1:0): "iomega jaz 1GB G.60" type 0 removable SCSI 2 sd1(ncr0:1:0): Direct-Access sd1(ncr0:1:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. sd1(ncr0:1:0): ILLEGAL REQUEST asc:24,0 Invalid field in CDB sd1 could not mode sense (4). Using ficticious geometry sd1(ncr0:1:0): NOT READY asc:3a,0 Medium not present sd1: could not get size 0MB (0 512 byte sectors) However, I doubt if this is JAZ specific; it seems more related to it being removable than anything else. (yes, the drive was spun up at the time, so you can't blame that). The eject was manual. Truly, when I press the eject button, an "umount -f" operation should occur on behalf of the FS's mounted on the drive... oh well. In any case, I have to wait a long time. NetBSD and OpenBSD running on the same hardware do not have the same delay. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.