On Nov 6, 2013, at 9:57 AM, Adam Goryachev <mailinglists@xxxxxxxxxxxxxxxxxxxxxx> wrote: > I would definitely use a bitmap.... I've found USB drives can be flaky > from time to time. A bitmap will reduce the resync time to minutes. eg, > today I had a similar issue where one 2TB drive is SATA/internal and one > is USB3/external. After bootup I started the array on just the internal > drive, so adding back the USB drive required a resync. It completed in > less than one minute due to the bitmap functionality. That sounds amazing. > >>> Depending on the current content of the array (with such low event >>> numbers, it looks like you may not have put data on yet, it might >>> be easier to just re-create the array (although that will do a >>> resync anyway, unless you force that to be skipped). >> >> Actually, prior to the array degradation I had been copying data to >> it for a several days straight (yeah, as I said the throughput is not >> very good, peaks at 21-27Mb/s for writes when 3 USB disks are >> involved in action simultaneously.. that is, copying from one disk to >> this two disk array, all three connected to the same computer… which >> I think is still a good number when you think about it!), so it has >> about 1TB of data that I wouldn't like to lose now :P > > You might find you have more than one real USB bus on the computer, > potentially you might get better performance if you move the three > devices to different USB buses. Also, the two members of the RAID1 would > behave better on different buses if possible. You may need to read your > motherboard manual, or trial and error to find this out. Actually, this is a great tip! I will look into this. > >>> Finally, it would be a good idea to work out how you reached this >>> point. You really want to avoid having this problem in 6 months >>> when you have 1.8TB of data on the drives…. >> >> True. So, my setup is an old Linux laptop that used to be my main >> workstation and as I've said before the array is connected to it via >> USB interface. This computer being a hybrid server/workstation now, >> runs GNOME as desktop environment and a VNC server, and most >> importantly for our discussion I treat it as a workstation and never >> shut it down in the night, instead I switch it to sleep >> mode/hybernate. And that's how the array got out of sync, I resumed >> the laptop from sleep and the array was already degraded, event >> counts mismatch and all. >> >> I will have to figure out how pm-utils treats raid devices when doing >> sleep/resume, maybe intervene and script --stop --scan via a pm user >> hooks. I think internal bitmaps will be of great help here, because >> it may take some trying to get it done right.] >> >> Unfortunately, abandoning this configuration will most probably be >> very time consuming, because the system is so heavily customized by >> now it will be still easier and quicker to make sure pm plays with >> the raid array nicely than to say install Ubuntu Server (or >> workstation that I assume is capable of handling arrays on >> sleep/resume just nicely). > > Have you considered just doing a shutdown instead of sleep/resume? > Presumably it will only sleep at night, and resume in the morning, so it > shouldn't take all that long to startup in the morning. You can probably > set the bios to automatically power on at a preset time in the morning a > few minutes before you would normally want to use it. See, this particular laptop runs on max memory it's motherboard can handle, and for whatever reason the test memory happens very slowly, so it takes about a minute or a minute and a half to just get to boot loader. Besides, I'm such a fan of sleep/resume because it allows for really quick suspend in those rare cases when electricity goes out (happens sometimes where I live), or when I just need to temporarily power off all the noisy equipment to have a nice nap lol And resuming from a sleep and having the system in the state where I left it is just so convenient. I see a lot of value in this functionality. It is perhaps about living comfortably, you know? Ivan -- 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
