from the swsusp.txt in "Using the code" 3rd paragraph
<
Either way it saves the state of the machine into active swaps and then
reboots. By the next booting the kernel's resuming function is either
triggered by swapon -a (which is ought to be in the very early stage of
booting) or you may explicitly specify the swap partition/file to resume
from with ``resume='' kernel option.
>
This seems to suggest that you have a choice. Which last time i checked,
you dont.
from the swsusp.txt in "How the code works" 2nd paragraph
Same thing as before basically. swapon -a does not trigger a resume
under warnings!
Ext3 fs seems to show no more of a risk than a non-journalling fs.
perhaps that problem is reiserfs only?
Also, mention of the swap files being described in fstab is made in
"Using the code" but no mention is made to how they must be loaded and
must be actual raw partitions. Files of course would not work as viable
swaps for resume because the fs would have to be mounted to load them.
and one more thing. What happens when you have multiple swap files all
of equal priority (normal swap conditions have a striping effect (like
raid)) Will swsusp choose one ? How do we know which one it chose? Is
it just the first one in /proc/swaps all the time? That kind of
behavior would be nice to document in swsusp.txt.
Thanks for the patches. it seems to work on my non X box (p4) just
fine. I'll have to risk disaster and try it out on a dri X session soon
since that's where the convenience would come into play.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/