Re: swapon and raid systems
> 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.
Reply to: