Geom / mount / AoE disk failure (fwd)

[Sam]

---------- Forwarded message ----------
Date: Mon, 18 Oct 2004 10:19:13 -0500 (EST)
From: Sam <sah at softcardsystems.com>
To: freebsd-arch at 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 at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"