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

[Chris Murphy]

On Thu, Mar 30, 2017 at 6:07 AM, Michael Chapman <mike at very.puzzling.org> wrote:

> 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.

That's their position.

Also, the same file system dirtiness and journal replay is needed on
ext4. The sample size is too small to say categorically that the same
problem can't happen on ext4 in the same situation. Maybe the grub.cfg
is readable, but maybe the kernel isn't, or the initramfs, or
something else.


> 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.

I wondered about it at the start, and asked about it on the XFS list
in the first post about the problem. The developers nearly died
laughing at the idea of doing journal replay in 640KiB of memory. They
said categorically it's not possible.


> 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.


 I think getting mount/umount exit codes reported in the journal when
systemd.log_level=debug should be a higher priority. We really ought
to find out exactly what's going on, so we don't have to speculate,
and I think it's handy to have anyway if it's not a PITA to implement.

I've retested after removing plymouth, and the problem isn't
reproducible; I've nominated the plymouth non-killable behavior as a
Fedora 26 blocker. So it should get fixed and upstreamed.




-- 
Chris Murphy