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

[Chris Murphy]

On Sun, Apr 9, 2017 at 5:17 AM, Lennart Poettering
<lennart at poettering.net> wrote:

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

> So, I am still puzzled why the file system people think that "sync()"
> isn't supposed to actually sync things to disk...

https://www.spinics.net/lists/linux-xfs/msg05113.html

The question isn't directly answered in there (it is part of the
thread on this very subject though). My guess at is that sync()
predates journaled file systems, and the expectations of sync() for a
journaled file system are basically just crash consistency, not all
metadata is on disk. Fully writing all metadata is expensive; as is
checking fixing it with an offline fsck. Both of those are reasons why
we have journaled filesystems. If sync() required all fs metadata to
commit to stable media it would make file systems dog slow. Every damn
thing is doing fsync's now. Before Btrfs had a log tree, workloads
with many fsyncs would hang the file system and the entire workfload
as well, so my guess is sync() meaning all fs metadata is committed on
ext4 and XFS would mean massive performance hits that no one would be
happy about.



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

Oh god - that's the opposite direction to go in. There's not even
pretend crash safety with those file systems. If they're dirty, you
must use an fsck to get them back to consistency. Even if the toy fs
support found in firmware will tolerate the inconsistency, who knows
what blocks it actually ends up loading into memory, you can just get
a crash later at the bootloader, or the kernel, or initramfs. That so
much consumer hardware routinely lies about having committed data to
stable media following sync() makes those file systems even less
reliable for this purpose. Once corrupt, the file system has no fail
safe or fallback like a journaled or COW file system. It's busted
until fixed with fsck.

-- 
Chris Murphy