Given what  you've described, then only drive that it would make sense to pull out would be the one that was dropped and then re-inserted.<br><br><br><div class="gmail_quote">On Jan 4, 2008 10:20 PM, Dennison Williams <
<a href="mailto:evoltech@2inches.com">evoltech@2inches.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">
> Did you try and re-insert the kicked-out drive as if it was clean, or did<br>> you try to re-sync it to the existing filesystem.  If the former, then<br>> that's a HUGE mistake because the data on the drive is no longer in sync
<br>> with what is on the other drives. (unless the entire filesystem was made<br>> read-only when (or before) the drive was dropped out.)<br><br></div>I re-inserted it with:<br>mdadm /dev/md0 --add /dev/sde<br>At which point it seemed to resync with the raid device (ie. the output
<br>of /proc/mdstat showed that it was incrementally syncing)<br><div class="Ih2E3d"><br>> Check the SMART logs for each of the drives to see if they've had any<br>> problems.<br><br></div>there are messages like this:
<br>/dev/sdc, failed to read SMART Attribute Data<br>...but this wasn't one of the disks that was removed from the raid device</blockquote><div class="Ih2E3d">If there are complaints about SDC, then I'd be inclined to do a long test of it 
<br>in smart. it's possible that the real problem started here.<br><br>A badblock read test (or just a dd if=/dev/sdc of=/dev/null) would also test the I/O path between the drive and the CPU. If there are complaints about that drive, then .. at this point, you should consider it suspicious.
<br> <br>><br>> Try pullling the (candidate) compromized drive out of the array and see if<br>> the (degraded) filesystem works OK and has good data.  If it does, then I'd<br>> guess that the pulled drive had bad data written to it somehow --- re-add it
<br>> (as if it was hot-swapped in), and hope it doesn't happen again.<br>> Try that with each of the  drives, in turn until you find the badly written<br>> drive.  If one of the drives has badly written data, the system really can't
<br>> tell, for sure, which one is wrong.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I want to make sure I understand you here.  Say my raid device is
<br>comprised of for devices /dev/md0 = /dev/sd[abcd], are you sugesting<br>that for each drive I do somthing like this:<br><br>mdadm /dev/md0 --fail /dev/sda --remove /dev/sda</blockquote><div>Don't bother. If the drive got resynced, then pulling it won't do any good unless software RAID gets silently confused by random data on one plex, 
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><br>then try to mount up the FS as usual to see if it is there?  Wouldn't<br>
this point be moot if the device already re-assembled itself?<br><div class="Ih2E3d"></div></blockquote><div>Yes. it would be moot. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>><br>> [[ unless the array was read-only when the drive was dropped, then you will<br>> only have any hope of good data with the dropped drive pulled ]]<br><br></div>It wasn't read-only, but nothing was writing to it.
<br><br>Thanks for your time and prompt response.<br>Sincerely,<br><font color="#888888">Dennison Williams<br></font></blockquote></div><br>Unless noatime was set, then the drive was being written to (if only atime data).  if all that got scrambled was atime data you should still have been able to mount the drive.
<br><br clear="all"><br>-- <br>Stephen Samuel <a href="http://www.bcgreen.com">http://www.bcgreen.com</a><br>778-861-7641