Re: [PATCH] vfs: freeze filesystems just prior to reboot

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux