On Mon, 10.04.17 19:07, Michael Chapman (m...@very.puzzling.org) wrote: > > So no, "freeze" is not an option. That sounds like a recipe to make > > shutdown hang. We need a sync() that actually does what is documented > > and sync the file system properly. > > sync() is never going to work the way you want it to work. Let's make > systemd work correctly for the systems we have today, not some hypothetical > system of the future.
It works the way I want on vfat, ext2. The problem you are having is specific to XFS, no? > The filesystem developers have good reasons for sync()'s current behaviour. > I can only point out again that the way they've designed it does *not* lose > or corrupt data: all synced data is available as soon as the filesystem > journals have been flushed. We have to explicitly flush the journals > ourselves, one way or another, to ensure that GRUB and other > not-fully-Linux-compatible filesystem implementations work correctly. The data *is* lost from the perspective of a boot loader. And given that /boot is pretty much exclusively about boot loading, that's kinda major. Note that these weird XFS semantics are not only a problem on systemd btw: they are much worse on sysvinit and other simpler init systems, since they generally don't have the kill/umount/remount/detach loop we have, and don't support transitioning back into the initrd for complete detaching/umounting of the root fs either. Hence, any claims by the xfs folks that systemd doesn't disassemble things the right way is very wrong: systemd is certainly the one implementation that has a better chance to keep xfs sane than any other... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
