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

[Lennart Poettering]

On Sun, 09.04.17 10:11, Michael Chapman (mike at very.puzzling.org) wrote:

> Don't forget, they've provided an interface for software to use if it needs
> more than the guarantees provided by sync. Informally speaking, the FIFREEZE
> ioctl is intended to place a filesystem into a "fully consistent" state, not
> just a "fully recoverable" state. (Formally it's all a bit hazy: POSIX
> really doesn't guarantee anything with sync.)

If FIFREEZE is a generic ioctl() supported by a number of different
file systems I figure it would be much more OK with calling it.

That said, are you sure FIFREEZE is really what we want there? it
appears to also pause any further writes to disk (until FITHAW is
called). Which isn't really what we are interested in here (note that
we return back to the initrd after the umount spree and it shall be
able to do the rest, and if it actually can do that, then the file
systems should be able to unmount and that usually results in writes
to disk...)

So, I am still puzzled why the file system people think that "sync()"
isn't supposed to actually sync things to disk... I mean, it appears
the call is pretty much useless and it's traditional usage (which
prominently is in sysvinit before reboot()) appears to be broken by
their behaviour.

Why bother with sync() at all, if it implies no guarantees? This is
quite frankly bullshit...

It appears to me that using /boot on a file system whith such broken
sync() semantics is really not a safe thing to do, and people should
probably only use something more reliable, i.e. ext2 or vfat where
sync() actually works correctly...

Lennart

-- 
Lennart Poettering, Red Hat