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

[Lennart Poettering]

On Mon, 10.04.17 19:07, Michael Chapman (mike at very.puzzling.org) wrote:

> > So no, "freeze" is not an option. That sounds like a recipe to make
> > shutdown hang. We need a sync() that actually does what is documented
> > and sync the file system properly.
> 
> sync() is never going to work the way you want it to work. Let's make
> systemd work correctly for the systems we have today, not some hypothetical
> system of the future.

It works the way I want on vfat, ext2. The problem you are having is
specific to XFS, no?

> The filesystem developers have good reasons for sync()'s current behaviour.
> I can only point out again that the way they've designed it does *not* lose
> or corrupt data: all synced data is available as soon as the filesystem
> journals have been flushed. We have to explicitly flush the journals
> ourselves, one way or another, to ensure that GRUB and other
> not-fully-Linux-compatible filesystem implementations work correctly.

The data *is* lost from the perspective of a boot loader. And given
that /boot is pretty much exclusively about boot loading, that's kinda
major.

Note that these weird XFS semantics are not only a problem on systemd
btw: they are much worse on sysvinit and other simpler init systems,
since they generally don't have the kill/umount/remount/detach loop we
have, and don't support transitioning back into the initrd for
complete detaching/umounting of the root fs either.

Hence, any claims by the xfs folks that systemd doesn't disassemble
things the right way is very wrong: systemd is certainly the one
implementation that has a better chance to keep xfs sane than any
other...

Lennart

-- 
Lennart Poettering, Red Hat