Date: Mon, 18 Oct 2004 10:19:13 -0500 (EST) From: Sam <sah@softcardsystems.com> To: freebsd-arch@freebsd.org Subject: Geom / mount / AoE disk failure Message-ID: <Pine.LNX.4.60.0410180948490.10774@athena>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.60.0410180948490.10774>