| 1 |
Marc Joliet posted on Tue, 24 Feb 2015 21:15:45 +0100 as excerpted: |
| 2 |
|
| 3 |
> Like I mentioned above, my Desktop can *almost* suspend reliably, |
| 4 |
> after trying it out once every year or two (it's over 8 years old). |
| 5 |
> Mostly it would just not wake back up. The latest status (before |
| 6 |
> systemd) was that the kernel crashed after waking up (but I think |
| 7 |
> that was a known bug that was fixed in the meantime). |
| 8 |
|
| 9 |
FWIW... for readers that might be considering multi-device filesystems |
| 10 |
(like btrfs can do if so configured) or mdraid/dmraid/etc type multi- |
| 11 |
device backed filesystems... |
| 12 |
|
| 13 |
What I've found with suspend/hibernate over the years and on multiple |
| 14 |
systems, is that while at least one or the other generally works, |
| 15 |
that's on the condition of no multi-device mdraid, dmraid, btrfs, etc. |
| 16 |
Once you get more than one physical device backing a filesystem, be |
| 17 |
that mdraid/ dmraid/etc, or a direct multi-device filesystem such as |
| 18 |
btrfs, suspend/ hibernate, or more precisely, the resume, becomes |
| 19 |
problematic, because invariably, one device lags the others in |
| 20 |
resuming, and the kernel apparently doesn't know how to properly wait |
| 21 |
for multiple devices to all resume and stabilize at once. |
| 22 |
|
| 23 |
The result is that the system resumes, but one or more physical devices |
| 24 |
underlying that multi-device filesystem often stabilizes slower than |
| 25 |
the others and gets dropped from the raid or whatever. |
| 26 |
|
| 27 |
If it's a raid0, without redundancy, that can mean you just lost it and |
| 28 |
everything on it, period. With other raid types it's not so bad, but |
| 29 |
it does often mean either manual missing-device delete and re-add |
| 30 |
(mdraid), or (on btrfs) a quick reboot as btrfs becomes unstable when a |
| 31 |
device drops and the system will often freeze or livelock if you don't, |
| 32 |
and then a scrub after the reboot brings the device back in, to sync |
| 33 |
the updates back to the device that was dropped and brought back in. |
| 34 |
|
| 35 |
So... after finding that about half the time after a suspend or |
| 36 |
hibernate and resume cycle you have to either reboot or do manual |
| 37 |
system maintenance anyway, pretty soon you learn not to bother with |
| 38 |
suspend/ hibernate in the first place, and simply shutdown, and restart |
| 39 |
from power- off when you'd otherwise resume. |
| 40 |
|
| 41 |
Back on spinning rust, this used to annoy me greatly, as the boot time |
| 42 |
wasn't bad, but it did mean starting with an empty cache, and losing |
| 43 |
that several gigs of cache of much slower spinning rust at the reboot |
| 44 |
was / painful/. |
| 45 |
|
| 46 |
While reasonably fast SSDs are still slower than cache, the difference |
| 47 |
is 2-3 orders of magnitude smaller, and losing the cache on reboot |
| 48 |
isn't the big deal it once was. Between that and the fact that systemd |
| 49 |
bootup is so fast on ssd, full shutdown and restart isn't such a big |
| 50 |
deal these days. |
| 51 |
|
| 52 |
But it sure would be nice if the kernel could learn to handle resume |
| 53 |
from suspend or hibernate much like it does bootup, using bootwait or |
| 54 |
similar kernel commandline option not just at boot, but at resume as |
| 55 |
well, so systems that can and do /boot/ multiple devices just fine, |
| 56 |
can /resume/ them just fine as well. Then we'd not have to worry about |
| 57 |
such problems. Oh, well... maybe someday... |
| 58 |
|
| 59 |
-- |
| 60 |
Duncan - List replies preferred. No HTML msgs. |
| 61 |
"Every nonfree program has a lord, a master -- |
| 62 |
and if you use the program, he is your master." Richard Stallman |
| 63 |
|
| 64 |
|
| 65 |
-- |
| 66 |
Duncan - No HTML messages please; they are filtered as spam. |
| 67 |
"Every nonfree program has a lord, a master -- |
| 68 |
and if you use the program, he is your master." Richard Stallman |
Archives