Hi, I've got a bugreport [0] from a user trying to use raid and uswsusp. He's using initramfs-tools available in debian. I'll describe the problem and my analysis, maybe you can comment on what you think. A warning: I only have a casual understanding of raid, never looked at any code related to it. This is a setup where root maybe on raid, but swap isn't. Swap on raid will be very difficult to support, I think. When s2disk is started, nothing special is done to the array. It may be in an unclean state (just like filesystems). Image is written to disk. After the power cycle the kernel boots, devices are discovered, among which the ones holding raid. Then we try to find the device that holds swap in case of resume and / in case of a normal boot. Now comes a crucial point. The script that finds the raid array, finds the array in an unclean state and starts syncing. After this, resume finds an image in the swap partition and starts the resume process. Part of this process is freezing everything but itself, which fails on the process/thread that does the syncing. IMO, the problem comes from the fact we started syncing, before we could start resume. Now the problem could theoretically be solved by not starting the assembly of the array once it is discovered, but modifying the initramfs to do the assembly after we have had the chance to resume. The debian-maintainer of mdadm thinks that the suspend process should have left the array in a clean state, but this is IMHO impossible. We are freezing userspace. A mdamd process looking after the array will probably get into trouble if we come back from suspend and we have done something to the array in the mean time. What do you think? grts Tim [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=415441
Attachment:
signature.asc
Description: PGP signature
