> I have a couple of systems that use kernel RAIDs (specifically, > mirrors). The systems also have regular (non-mirrored) partitions for > swap. When the systems boot, the swap partitions don't get installed. I > have isolated it to the fact that the boot scripts first grep for > "resync" in /proc/mdstat, and only run swapon if the grep fails (i.e, > there's no "resync" string in /proc/mdstat).
Which boot script is that? I can understand the logic of not wanting to swap on an md device that's getting a RAID resync, but it surprises me that even non-mirrored swap would be passed over as well. > Unfortunately, it appears that at boot time, these systems *always* have > resync in mdstat, because swap never seems to be added after a > reboot. Which leads to some questions: > > 1. what is the purpose of this check? > 2. is it normal for my raids to always be resyncing at boot (*)? > 3. suggestions for a good (maintainable) approach to ensuring that my > non-RAID swap partitions always get enabled at boot? > > (*) Thinking back, I think that all of the reboots on these systems have > been due to abnormal causes (i.e., a power failure yesterday), so > maybe resyncing is normal after unplanned reboots? All of my raidtools experience is with RedHat, but if you watch a graceful shutdown closely, the last thing the kernel should do is mark each RAID member's superblock with a clean flag. Then that's used when the device is raidstarted again. If all members are clean, then no resync is needed; otherwise, generally it is. I'm reasonably sure that's what forcing your resyncs at boot. I'd recommend watching a few graceful reboots closely to see exactly what's happening with the resyncs and with the swap activation.
