From owner-freebsd-geom@FreeBSD.ORG Mon Oct 18 14:37:19 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 223BD16A4CE for ; Mon, 18 Oct 2004 14:37:19 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id C907F43D41 for ; Mon, 18 Oct 2004 14:37:18 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i9IFZMH9011272 for ; Mon, 18 Oct 2004 10:35:22 -0500 Date: Mon, 18 Oct 2004 10:35:22 -0500 (EST) From: Sam X-X-Sender: sah@athena To: freebsd-geom@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Geom / mount / AoE disk failure (fwd) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2004 14:37:19 -0000 ---------- Forwarded message ---------- Date: Mon, 18 Oct 2004 10:19:13 -0500 (EST) From: Sam To: freebsd-arch@freebsd.org Subject: Geom / mount / AoE disk failure Hello all, I'm in final testing of the AoE driver for 5.3 and have a question about disk device failures for mounted filesystems. I have an ED blade on my desk that I can pull the power from. The driver has a timeout so that if the blade doesn't respond in N seconds, all outstanding IO is failed and the disk is either a) destroyed if not open or b) marked for destruction on final close. If I dd from the device, in this case /dev/aoed10, and pull the power mid transfer, dd fails and the device is removed on close as expected. If I mount a portion of the disk, /dev/aoed10s1a, and while dd'ing from a file on the mount pull the power, dd fails, but the mount point persists. This seems expected, but when I force the umount (umount -f), I never get a final close. I get this in the log: --- Oct 18 09:53:29 fivethree kernel: fsync: giving up on dirty: 0xc1805b58: tag devfs, type VCHR, usecount 2, writecount 0 , refcount 5, flags (VV_OBJBUF), lock type devfs: EXCL (count 1) by thread 0xc1341c80 (pid 40414) Oct 18 09:53:29 fivethree kernel: dev aoed10s1a Oct 18 09:53:37 fivethree kernel: fsync: giving up on dirty: 0xc1805b58: tag devfs, type VCHR, usecount 2, writecount 0 , refcount 5, flags (VV_OBJBUF), lock type devfs: EXCL (count 1) by thread 0xc1345190 (pid 40416) Oct 18 09:53:37 fivethree kernel: dev aoed10s1a Oct 18 09:53:37 fivethree kernel: fsync: giving up on dirty: 0xc1805b58: tag devfs, type VCHR, usecount 1, writecount 0 , refcount 5, flags (VV_OBJBUF), lock type devfs: EXCL (count 1) by thread 0xc1345190 (pid 40416) Oct 18 09:53:37 fivethree kernel: dev aoed10s1a Oct 18 09:53:58 fivethree kernel: fsync: giving up on dirty: 0xc1805b58: tag devfs, type VCHR, usecount 2, writecount 0 , refcount 5, flags (VV_OBJBUF), lock type devfs: EXCL (count 1) by thread 0xc142a190 (pid 40419) Oct 18 09:53:58 fivethree kernel: dev aoed10s1a Oct 18 09:53:58 fivethree kernel: fsync: giving up on dirty: 0xc1805b58: tag devfs, type VCHR, usecount 1, writecount 0 , refcount 5, flags (VV_OBJBUF), lock type devfs: EXCL (count 1) by thread 0xc142a190 (pid 40419) Oct 18 09:53:58 fivethree kernel: dev aoed10s1a Oct 18 09:53:59 fivethree kernel: fsync: giving up on dirty: 0xc1805b58: tag devfs, type VCHR, usecount 2, writecount 0 , refcount 5, flags (VV_OBJBUF), lock type devfs: EXCL (count 1) by thread 0xc112e960 (pid 40420) Oct 18 09:53:59 fivethree kernel: dev aoed10s1a Oct 18 09:53:59 fivethree kernel: fsync: giving up on dirty: 0xc1805b58: tag devfs, type VCHR, usecount 1, writecount 0 , refcount 5, flags (VV_OBJBUF), lock type devfs: EXCL (count 1) by thread 0xc112e960 (pid 40420) --- Please excuse the formatting, this mail client isn't the best. Is this the expected behaviour? Since I never get the final close, I can't reinitialize the device when I power it back up, unload the module, etc. Should I be doing something else to trigger that the device is gone besides just failing the bios (EIO)? Maybe there's something that GEOM is expecting that I'm not doing? Cheers, Sam _______________________________________________ freebsd-arch@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"