On Sun, Sep 25, 2011 at 1:35 PM, Theodore Ts'o <ty...@mit.edu> wrote: > > Hi there, > > Looking at this bug report. I'm going to guess the problem is that with > triple RAID1, the problem you had is based on the disks being out of > sync, and so that e2fsck got one version of one or more blocks when on > the first pass of running e2fsck, and another version of those blocks on > the second pass of running e2fsck. > > In any case, without a log of the e2fsck run, there's not much I can do > with this kind of bug report. > > If you can provide me with the transcript of the e2fsck run (see the > "REPORTING BUGS" section of the e2fsck man page for more details of the > sort of thing I need for a good bug report), I'll happily look at it. > > Otherwise, I propose to close this bug report with a tag of > "unreproducible".
yep - apologies, i meant to provide further info: it turns out that the western digital 1.5gb "green" drives are "unfit for purpose". the policy in western digital is to take drives off the production line and test them. if they pass, they're labelled as "black". if they fail, they're ramped down in speed a bit, tested again and labelled as "green". in this case however that 2nd batch of testing - by the manufacturer - was completely inadequate. even just attempting to re-sync the RAID was enough to push these drives - all four of them - over the edge into "intermittent unreliability". so by the time the sync had finished, there would be 170,000 RAID1 mismatch count errors. by the time a raid _sync_ had finished, there would be 170,000 RAID1 mis-matches. good one, huh? so, perhaps unsurprising that there was... uh... a bit of a problem with the file system. l. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
