On Fri, May 19, 2017 at 3:20 AM, Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote: > > Therefore, add a reboot hook to freeze all filesystems (which in general > will induce ext4/xfs/btrfs to checkpoint the log) just prior to reboot. > This is an unfortunate and insufficient workaround for multiple layers > of inadequate external software, but at least it will reduce boot time > surprises for the "OS updater failed to disengage the filesystem before > rebooting" case. > Darrick, Did you consider how many support calls this will generate for a stuck reboot command? I can think of at least one situation where this is guarantied to hang. See this patch for the details: https://patchwork.kernel.org/patch/6266791/ The referenced patch was applied to Android kernel to prevent system crash on emergency remount-ro via sysrq trigger. I don't know if it was even seriously considered by Al, because I got no comment, but I do realize that the change of behavior could generate support calls, so it's scary to make that change in mainline. I know it's not going to work around broken system software update, but how about providing sysrq trigger for emergency_freeze_all()? like emergency_remount(), but stronger. And this time, iterate supers in reverse order like I suggested to avoid loop mounted fs freeze dependencies. There is one little tiny problem though. Eric used up the last sysrq trigger key for emergency_thaw_all(). Do you see the irony in that? ;) I am wondering how many people know about or use the emergency thaw trigger, but one dodgy option is to use the 't' trigger to toggle thaw_all/freeze_all. Another perhaps slightly less dodgy option is to trigger freeze_all on a sequence of sysrq "emergency" triggers where it makes sense and is least likely to change any existing behavior, for example: echo u > /proc/sysrq-trigger # Remember if do_emergency_remount() completed with failures echo u > /proc/sysrq-trigger # Escalate to emergency freeze OR echo u > /proc/sysrq-trigger # Remember if do_emergency_remount() completed with failures echo s > /proc/sysrq-trigger # Sync *after* remount r/o? That must mean emergency freeze I bet that system software that is already aware of and is issuing emergency remount r/o trigger prior to reboot, won't see any harm in adding an extra u/s trigger for good luck. Do you know if the gnarly system software in question is issuing emergency remount r/o prior to reboot? Amir.
