From owner-freebsd-hackers Sun Jan 12 17:32:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA09438 for hackers-outgoing; Sun, 12 Jan 1997 17:32:42 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA09432 for ; Sun, 12 Jan 1997 17:32:38 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id MAA13813; Mon, 13 Jan 1997 12:00:42 +1030 (CST) From: Michael Smith Message-Id: <199701130130.MAA13813@genesis.atrad.adelaide.edu.au> Subject: Re: mount -o async on a news servre In-Reply-To: <199701121947.MAA26105@phaeton.artisoft.com> from Terry Lambert at "Jan 12, 97 12:47:36 pm" To: terry@lambert.org (Terry Lambert) Date: Mon, 13 Jan 1997 12:00:40 +1030 (CST) Cc: dg@root.com, terry@lambert.org, joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] 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 Lambert stands accused of saying: > > I have had delays on the order of a minute when umounting my JAZ disk. Sounds like you have a bug in your FS patches then. I beat the living crap out of mine on a regular basis (eg. 'make build' for NetBSD NFS clients, FreeBSD CVS repository, etc.), and 'umount' invariably gives a quick squitter and then the drive is ready to eject. > 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: Huh? How do "other BSD's" handle reading the media size from a drive that handles variable size media? I think you're dreaming again. > sd1(ncr0:1:0): ILLEGAL REQUEST asc:24,0 Invalid field in CDB > sd1 could not mode sense (4). Using ficticious geometry ... > However, I doubt if this is JAZ specific; it seems more related to it > being removable than anything else. Actually, it has to do with the people who did the SCSI firmware saying "modepage 4? On a ZBR drive? You've got to be kidding". And getting away with it. > sd1(ncr0:1:0): NOT READY asc:3a,0 Medium not present > sd1: could not get size > 0MB (0 512 byte sectors) > ... > (yes, the drive was spun up at the time, so you can't blame that). Well it shure as shit didn't think it was spun up. There's not much the scsi code can do if the drive says it's empty. > 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. ... yet you loathe polling the device for status? Well, I guess you could require that the device support being a master as well as a slave, and add however much (cost) to it. Yay. Not. > In any case, I have to wait a long time. NetBSD and OpenBSD running > on the same hardware do not have the same delay. ... probably because you're not running with your hacked kernel on them. > Terry Lambert -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[