On 26 February 2011 11:20, Leslie Rhorer <lrhorer@xxxxxxxxxxx> wrote: > > >> -----Original Message----- >> From: linux-raid-owner@xxxxxxxxxxxxxxx [mailto:linux-raid- >> owner@xxxxxxxxxxxxxxx] On Behalf Of Jeff Woods >> Sent: Saturday, February 26, 2011 1:36 AM >> To: lrhorer@xxxxxxxxxxx >> Cc: 'Linux RAID' >> Subject: Re: OK, Now this is really weird >> >> Quoting Leslie Rhorer <lrhorer@xxxxxxxxxxx>: >> > Â Â I have a pair of drives each of whose 3 partitions are members of a >> > set of 3 RAID arrays. ÂOne of the two drives had a flaky power >> connection >> > which I thought I had fixed, but I guess not, because the drive was >> taken >> > offline again on Tuesday. ÂThe significant issue, however, is that both >> > times the drive failed, mdadm behaved really oddly. ÂThe first time I >> > thought it might just be some odd anomaly, but the second time it did >> > precisely the same thing. ÂBoth times, when the drive was de-registered >> by >> > udev, the first two arrays properly responded to the failure, but the >> third >> > array did not. ÂHere is the layout: >> >> [snip lots of technical details] >> >> > Â Â So what gives? Â/dev/sdk3 no longer even exists, so why hasn't it >> > been failed and removed on /dev /md3 like it has on /dev/md1 and >> /dev/md2? >> >> Is it possible there has been no I/O request for /dev/md3 since >> /dev/sdk failed? > > Â Â Â ÂWell, I thought about that. ÂIt's swap space, so I suppose it's > possible. ÂI would have thought, however, that mdadm would fail a missing > member whether there is any I/O or not. > > -- > To unsubscribe from this list: send the line "unsubscribe linux-raid" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at Âhttp://vger.kernel.org/majordomo-info.html > I thought so as well. But how will mdadm know is the device is faulty, unless the device is generating errors? (which usually only happens on read and/or write) // Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
