From owner-freebsd-scsi Mon Sep 18 12:28:34 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.prod.itd.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 21CFD37B423 for ; Mon, 18 Sep 2000 12:28:32 -0700 (PDT) Received: from veager.siteplus.net (1Cust10.tnt10.chattanooga.tn.da.uu.net [63.22.145.10]) by falcon.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with ESMTP id MAA07476; Mon, 18 Sep 2000 12:28:18 -0700 (PDT) Date: Mon, 18 Sep 2000 15:28:11 -0400 (EDT) From: Jim Weeks To: Bruce Evans Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: umount -f question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 19 Sep 2000, Bruce Evans wrote: > umount -f doesn't try hard enough to force the unmount, at least for ffs. > ffs_unmount() uses the -f flag only for flushing files. Then, if the > filesystems mounted rw, it always attempts to update the superblock, and > this should always fail if the drive has died. I ignore errors from > this in my version of ffs_vfsops.c (I should only ignore them in the -f > case). If the superblock update succeeds, then ffs_unmount() is committed > to the mount succeeding, but the unmount can still fail if closing the > device fails, as probably happens if the device has died. This may cause > memory leaks or worse because dounmount() doesn't understand half > successful unmounts. > > Failure of the other commands is correct because they involve opens and > the driver shouldn't allow opening dead devices. > > Bruce Thanks for the insight. Then as I understand it there would be no way of freeing up the mount point as long as the drive is hung in this way? Since this is a production machine I couldn't afford to remote reboot untill someone was near the machine. After I did reboot I was able to fsck the disk and remount. These are the messages produced during fsck. # fsck /dev/da1s1e ** /dev/rda1s1e ** Last Mounted on /bak ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? [yn] y SUMMARY INFORMATION BAD SALVAGE? [yn] y BLK(S) MISSING IN BIT MAPS SALVAGE? [yn] y 103452 files, 1802476 used, 6892603 free (5251 frags, 860919 blocks, 0.1% fragme ntation) ***** FILE SYSTEM MARKED CLEAN ***** ***** FILE SYSTEM WAS MODIFIED ***** It is just hard to belive that there is no other way of getting back on track without a reboot. -- Jim Weeks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message