Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

Since upgrading to 11.04 I have been trying to get my 5 disk RAID5 array back online. The array was initially split in two, I tried to use a create command with the assume clean option to get it back into a single array. I think this did more harm than good because the mdadm default is now to use the 1.2 rather than 0.90 metadata format which I believe caused the metadata to be written over some of my data. This brought into doubt the disk ordering I thought the array should have as this order will not result in a mountable drive so I used a script to test every possible ordering of the five disks and none of them mounted, I then tried the same process only instead of mounting I ran an xfs_check and then a targetted xfs_repair (with the -n option to prevent any actual edits).

All this got me down to a reasonably small collection of disk layouts but I obviously only get one change to try the xfs_repair and the data is far to large to try an backup so I thought having the array run a parity check would be a good idea, I started out with the two array disk orderings I thought most likely to be correct ran check and as it turns out they both had exactly 8 for a mismatch_count and those 8 were discovered almost instantly. How is this possible? The two disk orderings are very different (acbde vs adcbe)...is it possible disk order will have no effect on a parity check? Just on the actual underlying data? If so it might be reasonable to try to run a repair on the array from one of these layouts and then recheck the file-system to see if it can now mount...but I am hesitant to do so as it would be the first step I have taken that intentionally writes more than metadata to the disks.

share|improve this question

2 Answers 2

Anyone curious, it turns out my issue was a second default change between array creation and the version of mdadm i ran me new create on, the stripe size default had been 64k and it is now 512k. Switching to 64k solved my issue.

share|improve this answer
    
FYI mismatch_count tracks pages that are out of sync in the array. It's a poor man's disk scrubber that guards against bit rot. It's documented in the kernel docs: lxr.linux.no/linux+v3.1.2/Documentation/md.txt. I suspect your previous alignment choice was creating unaligned accesses that may have actually created stale entries. It might be worthy of a bug report. –  ppetraki Nov 22 '11 at 15:14

This really sounds like a topic best suited for the md list. Neil Brown will know best regarding your metadata update and how it might impact the disk scrubber. If it turns out not to be a problem then you're just a 'repair > sync_action' away from repairing your array.

share|improve this answer
    
Thanks for the advice I will try posting there. –  lostatredrock May 5 '11 at 15:17

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.