I have two internal 4TB hard drives and I've just started using software RAID1 in Debian Wheezy. I have a few questions:

1) During boot, everything passes except I get a message that reads "RAID status not ok." Everything seems to work fine. I can read/write to the RAID array just fine. I've set up the partitions as follows:
10MB on /dev/sda and 10MB on /dev/sdb -> /dev/mdb1 (swap space)
4TB on /dev/sda and 4TB on /dev/sdb -> /dev/mdb2 (ext4 root partition)
1MB biosgrub on each drive
During the partition creation phase of the installation, the installer complained saying that /dev/mdb1 (swap) couldn't be altered as it was being used. Installation got interrupted the first time round and I had to run the installer again a second time. So, I just ignored it and left /dev/mdb1 as it was. This RAID status message during boot is bugging me. What is it and what can I do to fix it?

2) What is the purpose of resyncing? Viewing the contents of /proc/mdstat tells me that it's resyncing (which by the way seems to be going VERY slow). When I write to the RAID array, doesn't the data being written get mirrored across both drives? Or does it only get written to one drive and resyncing takes care of mirroring at a later stage? If the latter is true, how often does resyncing happen? It's a pain.

3) Is there a Debian tool that allows me to view the contents of each of the individual drives? I'd like to view the contents of each drive as a manual check to see whether they both contain the same data.


My take on these questions, in order asked:

  1. "RAID status not ok." supposedly means that resyncing is not done yet, so it's not safe to fail a drive in the array (from the point of view of the RAID subsystem).

    What is it and what can I do to fix it?

    Just let the RAID subsystem finish array synchronization.

  2. The purpose of resyncing is that the RAID subsystem must ensure the data portions on both drives are identical and then mark the superblocks on all the array members as being "up-to-date".

    The data written to the device exported by a mirror array is written to all the active array members and does not interfere with resyncing. Resyncing basically means scanning the address space of all the array members from start to end and ensuring all the array members have the same data; when some data is written to all these members at the same address this obviously does not hurt resyncing which strives to achieve the same goal, just globally.

  3. This is a wrong approach: a RAID subsystem does not guarantee you have "readable" data on each member of a RAID array, even if it is a mirror. Linux software RAID does indeed keep the data on each mirror array member "as is" — as if there was no mirror, — just a small superblock is maintained at the end of each member's medium.

    This means you can read each device (those /dev/sdX) constituting a mirror array individually, but this is generally a bad idea which is only ever employed when you've recovered a single member from a faulty mirror array and plugged it into another machine to read the data off its partitions.

TL;DR: Let the mirror finish synching and the problems should go away.

  • Nicely explained! Thanks kostix. The resyncing is finally finished and I rebooted the system. The RAID error seems to have vanished, so I suppose that's good. A couple more questions: 1) How often does resyncing happen and can that be controlled? 2) According to what you've said, resyncing is what determines the data integrity accross the individual drives, so I'll trust it to inform me if there's something wrong. Does it report errors somewhere besides /proc/mdstat and can something be setup to email if an error occurs?
    – Ash
    Aug 9 '13 at 0:46
  • @Ash, sorry for the delay. 1) By default, it happens once -- when initializing an array. You might set up periodic integrity checks -- see below. 2) Yes. All this stuff (resyncing, error reporting) is currently done in debian by the mdadm package which not only provides a management binary (mdadm itself) but is also able to 1) schedule array integrity checks; 2) run mdadm in a special "monitoring" mode making it mail root if any array error is detected. Run dpkg-reconfigure -plow mdadm and answer the questions it asks.
    – kostix
    Aug 12 '13 at 11:38
  • @Ash, also, if you run your array on consumer-grade SATA/SAS drives supporting SMART, consider installing smartmontools and enabling the smartd daemon it provides. You should tweak its default config file though: comment out the DEVICESCAN directive there and provide one configuration line for each of your drives, instructing smartd to run daily short self-tests and long self-tests on weekends on your drives. This will allow you to delect certain possible pre-failure states of your drives early.
    – kostix
    Aug 12 '13 at 11:41
  • Thank you for that. I will have a look at smartmontools when I get the chance.
    – Ash
    Aug 20 '13 at 2:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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