From owner-freebsd-arch@FreeBSD.ORG Mon Oct 18 14:21:11 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19ED916A4CE for ; Mon, 18 Oct 2004 14:21:11 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5350543D46 for ; Mon, 18 Oct 2004 14:21:10 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i9IFJDeM011154 for ; Mon, 18 Oct 2004 10:19:13 -0500 Date: Mon, 18 Oct 2004 10:19:13 -0500 (EST) From: Sam X-X-Sender: sah@athena To: freebsd-arch@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Geom / mount / AoE disk failure X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2004 14:21:11 -0000 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