On November 22, 2011, wilsonjonathan wrote: > Having looked more indepth I think the answer to my first question may > be resolved by increasing the wait time in the individual sd* devices as > if I read it correctly soft raid doesn't have or use a time out value > (unless it does both have and use the value under the md* device) but > instead just waits until an individual device times out. > > If thats the case then I may just increase the time out of the sd*'s to > 60 seconds from 30 seconds which should be more than enough time to > allow a drive to wind up and start to give back data. > > > Thanks for the helpful replies... > > > > I do have a couple of related questions... > > > > > > I have already done some testing by setting up sd[ab] for md[2-4] but > > > with no file systems on top, and then pulling sdb and then putting it > > > back in. > > > > > > q1, why does -add throw up the message : not performing --add, re-add > > > failed, zero superblock... > > > > Because some people seem to use "--add" when they mean "--re-add" and > > that can cause data loss. So to be safe, if want want to discard all > > the data on a device and add it as a true spare, you now need to > > --zero-superblock first. Hopefully that isn't too much of a burden. > > Thats what I thought was strange, as no data had changed (no file > system) after getting the above message when I tried --re-add I expected > it to add it back in and re-sync, but again it told me I couldn't so I > had to zero the supper block. > > > > q2, I setup md4 as a raid10 far 2, and I may not be understanding > > > raid10 here; when I zero the superblock to add it as I did with the > > > other raids which worked ok, for some reason it causes sda4 to drop > > > out and kills the whole md4 raid. > > > > You must be running linux-3.1. It has a bug with exactly this behaviour. > > It should be fixed in the latest -stable release. Upstream commit > > > > 7fcc7c8acf0fba44d19a713207af7e58267c1179 > > > > fixes it. > > Thanks for that... I'm currently running an older kernel now as I'm > installing debian squeeze to further test the raids with a running > system (as opposed to off a live cd) > > > > q3, Is it preferable to have a write intent bitmap, and if so should I > > > put it in the meta-data as opposed to a file. > > > > A write intent bitmap can make writes a little slower but makes resync > > after a crash much master. You get to choose which you want. > > It is much more convenient in the internal metadata. Having the bitmap > > in an external file and reduce the performance cost a bit (if the file > > is on a separate device). > > I would only recommend a separate file if you have an asymmetric mirror > > with one leg (the slow leg) marked write-mostly. You don't really want > > the bitmap on that device, so put it somewhere else. > > I will use the intent as you describe as the speed hit isn't a problem > for my use-case. Good call :) I started using the write-intent bitmap, and I can say I'll likely never go back to not using one. When there is a problem, you will appreciate the decision. Instead of it taking days or weeks to rebuild/resync, it takes a few minutes. And rebuilding is usually the point when a failure is going to happen, which is the absolute worst time, as losing a disk when degraded is pretty bad on many setups (raid0, raid1, raid5, some raid10's I think...). And I really don't notice the speed hit. I still get a few hundred MB/s at the very least off my 7 disk raid5. > > NeilBrown > > Jon > > -- > 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 -- Thomas Fjellstrom thomas@xxxxxxxxxxxxx -- 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
