Re: Systemd migration: opinion and questions

Marc Joliet posted on Tue, 24 Feb 2015 21:15:45 +0100 as excerpted:

> Like I mentioned above, my Desktop can *almost* suspend reliably,
> after trying it out once every year or two (it's over 8 years old).
> Mostly it would just not wake back up.  The latest status (before
> systemd) was that the kernel crashed after waking up (but I think
> that was a known bug that was fixed in the meantime).

FWIW... for readers that might be considering multi-device filesystems 
(like btrfs can do if so configured) or mdraid/dmraid/etc type multi-
device backed filesystems...

What I've found with suspend/hibernate over the years and on multiple 
systems, is that while at least one or the other generally works,
that's on the condition of no multi-device mdraid, dmraid, btrfs, etc.
Once you get more than one physical device backing a filesystem, be
that mdraid/ dmraid/etc, or a direct multi-device filesystem such as
btrfs, suspend/ hibernate, or more precisely, the resume, becomes
problematic, because invariably, one device lags the others in
resuming, and the kernel apparently doesn't know how to properly wait
for multiple devices to all resume and stabilize at once.

The result is that the system resumes, but one or more physical devices 
underlying that multi-device filesystem often stabilizes slower than
the others and gets dropped from the raid or whatever.

If it's a raid0, without redundancy, that can mean you just lost it and 
everything on it, period.  With other raid types it's not so bad, but
it does often mean either manual missing-device delete and re-add
(mdraid), or (on btrfs) a quick reboot as btrfs becomes unstable when a
device drops and the system will often freeze or livelock if you don't,
and then a scrub after the reboot brings the device back in, to sync
the updates back to the device that was dropped and brought back in.

So... after finding that about half the time after a suspend or
hibernate and resume cycle you have to either reboot or do manual
system maintenance anyway, pretty soon you learn not to bother with
suspend/ hibernate in the first place, and simply shutdown, and restart
from power- off when you'd otherwise resume.

Back on spinning rust, this used to annoy me greatly, as the boot time 
wasn't bad, but it did mean starting with an empty cache, and losing
that several gigs of cache of much slower spinning rust at the reboot
was / painful/.

While reasonably fast SSDs are still slower than cache, the difference
is 2-3 orders of magnitude smaller, and losing the cache on reboot
isn't the big deal it once was.  Between that and the fact that systemd
bootup is so fast on ssd, full shutdown and restart isn't such a big
deal these days.

But it sure would be nice if the kernel could learn to handle resume
from suspend or hibernate much like it does bootup, using bootwait or
similar kernel commandline option not just at boot, but at resume as
well, so systems that can and do /boot/ multiple devices just fine,
can /resume/ them just fine as well.  Then we'd not have to worry about
such problems.  Oh, well... maybe someday...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


-- 
Duncan - No HTML messages please; they are filtered as spam.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman