Will the system make sure that mdadm is sync-ed before completing a reboot?

Question

This is a follow up to my crazy mdadm problem. I'm trying to figure out what might have caused sda to get out of sync in the first place. The only thing I can think of is that I had just run a bunch of updates and was rebooting to reload the kernel upgrade. Is it possible that both drives hadn't synced? would the system prevent a reboot if there was mdadm syncing going on? could it be made to? any other suggestions as to what might have happened? and how it could be prevented in the further. Nothing seems to be wrong with the drive.

Answer 1

It certainly does on a clean shutdown:

• The Debian mdadm FAQ implies the kernel does the right thing:

  ​8. (One of) my RAID arrays is busy and cannot be stopped. What gives?
  It is perfectly normal for mdadm to report the array with the root filesystem to be busy on shutdown. The reason for this is that the root filesystem must be mounted to be able to stop the array (or otherwise /sbin/mdadm does not exist), but to stop the array, the root filesystem cannot be mounted. Catch 22. The kernel actually stops the array just before halting, so it's all well.

• The md driver sets all devices as read-only on shutdown (and even gives the physical devices about one second to settle).

Even if your system crashes in the middle of a write, the driver does take care to mark blocks as dirty while they're being written to, and to resync dirty blocks if it starts from an unclean array. See the comments regarding array states. The kernel documentation warns that arrays that are both dirty (not cleanly shut down) and degraded (having missing pieces) are not assembled automatically as this wouldn't be safe. When you assemble a dirty array, you'll (possibly very briefly) see it resync in /sys/block/md99/md/rd0/state. All in all, the md driver takes care of protecting your data against a total failures of a hardware component (CPU or disk), which is what's expected of it.

What md won't protect you against is data corruption due to a Byzantine failure (i.e. silent flipping of one or more bits) in RAM, CPU, motherboard, or disk. The disk hardware has checksums, but they're not perfect (see e.g. Zfs promotional literature). Zfs and Btrfs can protect against storage device corruption. Btrfs's checksum tree ensures that you will be notified if your hard disk flips a bit. Zfs offers a choice of checksum (according to Jeff Bonwick's Blog), up to SHA-256 which protects not only against random corruption but even against deliberate attack, at the cost of CPU cycles.

Answer 2

Did you create the raid1 bevore you put a filesystem onto it? If not - did you shrink the filesystem before making it a raid device?

If you did not the result might be a bad superblock on your raid-device.