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

[Michael Chapman]

On Thu, 30 Mar 2017, Lennart Poettering wrote:
[...]
> I am sorry, but XFS is really broken here. All init systems since time
> began kinda did the same thing when shutting down:
>
> a) try to unmount all fs that can be unmounted
> b) for the remaining ones, try to remount ro (the root fs usually qualifies)
> c) sync()
> d) reboot()
>
> That's how sysvinit does it, how Upstart does it, and systemd does it
> the same way. (Well, if the initrd supports it we go one step further
> though, and optionally pivot back to the initrd which can then unmount
> the root file system, too. That's a systemd innovation however, and
> only supported on initrd systems where the initrd supports it)
>
> If the XFS devs think that the sync() before reboot() can be partially
> ignored, then I am sorry for them, but that makes XFS pretty much
> incompatible with every init system in existence.
>
> Or to say this differently: if they expect us to invoke some magic
> per-filesystem ioctl() before reboot(), then that's nonsense. No init
> system calls that, and I am strongly against such hacks. They should
> just fix their APIs.
>
> Moreover, the man page of sync() is pretty clear on this:
>
>          "sync() causes all pending modifications to file system
>          metadata and cached file data to be written to the
>          underlying filesystems."
>
> It explicitly mentions metadata. Any way you turn it, the XFS folks
> are just confused if they really claim sync() doesn't have to sync
> metadata. History says differently, and so does the man page
> documentation.

I am not a filesystem developer (IANAFD?), but I'm pretty sure they're 
going to say "the metadata _is_ synced, it's in the journal". And it's 
hard to argue that. After all, the filesystem will be perfectly valid the 
next time it is mounted, after the journal has been replayed, and it will 
contain all data written prior to the sync call. It did exactly what the 
manpage says it does.

The problem here seems to be that GRUB is an incomplete XFS 
implementation, one which doesn't know about XFS journalling. It may be a 
good argument XFS shouldn't be used for /boot... but the issue can really 
arise with just about any other journalled filesystems, like Ext3/4.

As Mantas Mikulėnas points out, the FIFREEZE ioctl is supported wherever 
systemd is, and it's not just XFS-specific. I think it'd be smartest just 
to use it because it's there, it's cheap, and it can't make things worse.

-- 
Michael