On Mon, 10 Apr 2017, Lennart Poettering wrote:
On Mon, 10.04.17 16:14, Michael Chapman (m...@very.puzzling.org) wrote:
On Mon, 10 Apr 2017, Chris Murphy wrote:
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
Ah good, Dave actually suggests using a freeze there. A freeze without a
corresponding thaw should be OK if it's definitely after all processes have
been killed, since we're just about to reboot anyway. (Obviously we'd want
to avoid the whole lot when running in a container or when doing
kexec.)
No, there is no such guarantee. We support initrds that run userspace
stuff from the initrd at boot, that stays around in the background is
only killed after we transition back into the initrd. And we really
don't control what they do, they can do anything they like, access any
file they want at any time. We added this primarily to support storage
services backing the root file system (think iscsid, nbd, ...), but it
actually can be anything that hsa the "feel" of a kernel component in
being around since the time before systemd initialiazes until after
the time it shut down again, but is actually implemented in userspace.
In fact, this is precisely what plymouth is making use of: by marking
a process with argv[0][0] = '@' we permit any privileged process to be
excluded from the final killing spree, so that it will survive until
the initrd shutdown transition.
This is precisely why I intend to add it _just before_ the reboot(2) call.
Any processes that have survived that far are going to stop running a very
short moment later anyway; it doesn't matter if they get hung on a write.
Note that I am specifically NOT talking about doing a filesystem freeze
on the shutdown-initrd transition. That would be ludicrous.
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.
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.
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
