[systemd-devel] more verbose debug info than systemd.log_level=debug?

[Kai Krakow]

Am Mon, 10 Apr 2017 11:04:45 +0200
schrieb Lennart Poettering <lennart at poettering.net>:

> > Remember, all of this is because there *is* software that does the
> > wrong thing, and it *is* possible for software to hang and be
> > unkillable. It would be good for systemd to do the right thing even
> > in the presence of that kind of software.  
> 
> Yeah, we do what we can.
> 
> But I seriously doubt FIFREEZE will make things better. It's just
> going to make shutdowns hang every now and then.

It could simply thaw the FS again after freeze to somewhat improve on
that. At least everything that should be flushed is now flushed at that
point and grub et al should be happy.

But I wonder why filesystems not just flush the journal on remount-ro?
It may take a while but I think that can be perfectly expected when
rmounting ro: At least I would expect that this forces out all pending
writes to the filesystem hence flushing the journal.

Tho, readonly mounts do not guarantee the filesystem not modifying the
underlying storage device. For example, btrfs can modify the storage
even when mounting an unmounted fs in ro mode. It guarantees readonly
from user-space perspective - and I think that's totally on par with the
specs of "mount -o ro".

So a final freeze/thaw cycle is probably the only way to go? As it
specifies what is needed here to be compatible with configurations that
involve grub on complex filesystems.

Then, what's with underlying cache infrastructures like BBU-supported
RAID caches? We had systems that failed on reboot because the BBU was
in relearning cycle at reboot and the controller thus refused to replay
the write-cache during POST and instead discarded it. That can really
create you a big mess, btw. Tho, I think that's a controller bug: The
writeback wasn't set to always writeback but only when it's safe. But
this suggests that the reboot code should even force some cache flush
for those components.

Taken everything into account it boils down to eventually not using
grub on XFS but only simple filesystems, or depend on ESP only for
booting. Everything else only means that systemd (and other init
systems) have to invent a huge complex mess to fix everything that
isn't done right by other involved software.

-- 
Regards,
Kai

Replies to list-only preferred.