Am Mon, 10 Apr 2017 11:04:45 +0200 schrieb Lennart Poettering <lenn...@poettering.net>:
> > Remember, all of this is because there *is* software that does the > > wrong thing, and it *is* possible for software to hang and be > > unkillable. It would be good for systemd to do the right thing even > > in the presence of that kind of software. > > Yeah, we do what we can. > > But I seriously doubt FIFREEZE will make things better. It's just > going to make shutdowns hang every now and then. It could simply thaw the FS again after freeze to somewhat improve on that. At least everything that should be flushed is now flushed at that point and grub et al should be happy. But I wonder why filesystems not just flush the journal on remount-ro? It may take a while but I think that can be perfectly expected when rmounting ro: At least I would expect that this forces out all pending writes to the filesystem hence flushing the journal. Tho, readonly mounts do not guarantee the filesystem not modifying the underlying storage device. For example, btrfs can modify the storage even when mounting an unmounted fs in ro mode. It guarantees readonly from user-space perspective - and I think that's totally on par with the specs of "mount -o ro". So a final freeze/thaw cycle is probably the only way to go? As it specifies what is needed here to be compatible with configurations that involve grub on complex filesystems. Then, what's with underlying cache infrastructures like BBU-supported RAID caches? We had systems that failed on reboot because the BBU was in relearning cycle at reboot and the controller thus refused to replay the write-cache during POST and instead discarded it. That can really create you a big mess, btw. Tho, I think that's a controller bug: The writeback wasn't set to always writeback but only when it's safe. But this suggests that the reboot code should even force some cache flush for those components. Taken everything into account it boils down to eventually not using grub on XFS but only simple filesystems, or depend on ESP only for booting. Everything else only means that systemd (and other init systems) have to invent a huge complex mess to fix everything that isn't done right by other involved software. -- Regards, Kai Replies to list-only preferred. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel