Am Mon, 10 Apr 2017 13:54:27 +0200 schrieb Lennart Poettering <[email protected]>:
> On Mon, 10.04.17 13:43, Kai Krakow ([email protected]) wrote: > > > Am Mon, 10 Apr 2017 11:04:45 +0200 > > schrieb Lennart Poettering <[email protected]>: > > > [...] > > > > > > 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. > > Well, the remount-ro doesn't succeed in the case this is all about: > the plymouth process appears to run off the root fs and keeps the > executable pinned, which was deleted because updated, and thus the > kernel will refuse the remount. See other mail. Ah okay, so given that case, a journal flush even isn't attempted, it fails right away. My first idea was that it should flush the journal but can fail anyways. I didn't get that point. Thus my assumption that remount-ro doesn't flush the journal. > > 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. > > A pair of FIFREEZE+FITHAW are likely to work, but it's frickin' ugly > (see other mails), and I'd certainly prefer if the fs folks would > provide a proper ioctl/syscall for the operation we need. Quite > frankly it doesn't appear like a particularly exotic operation, in > fact the operation we'd need would probably be run much more often > than the operation that FIFREEZE/FITHAW was introduced for... Yes it's ugly and there should be a proper ioctl/syscall for the exact semantics needed. Usually, working around such missing APIs only results in the needed bits never implemented. I totally understand your point. ;-) -- Regards, Kai Replies to list-only preferred. _______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
