Geom / mount / AoE disk failure
From: Sam (sah_at_softcardsystems.com)
Date: 10/18/04
- Previous message: Scott Long: "Re: Removal of /stand Directory"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 18 Oct 2004 10:19:13 -0500 (EST) To: freebsd-arch@freebsd.org
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"
- Previous message: Scott Long: "Re: Removal of /stand Directory"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
