On Sun, Apr 9, 2017 at 5:17 AM, Lennart Poettering <lenn...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
