Re: [PATCH] ext4: guarantee already started handles to successfully finish while ro remounting

[tytso@mit.edu]

On Fri, May 06, 2016 at 02:01:17PM -0600, Andreas Dilger wrote:
> 
> The problem is that emergency remount-ro doesn't block in-progress writes,
> since most operations only check the MS_RDONLY at the start of an operation.
> It would be possible for do_emergency_remount() call ->freeze_fs() first for
> all the filesystems, then doing the remount read-only (would need a change to
> do_remount_ro() to allow this)?

I thought about doing that, but that would mean that the code path
might need to take some locks along the way, and if you have multiple
file systems, for which one has wedged, the do_emergency_remount()
function might end up blocking when it tries calling freeze_fs() on
one of the file system before it managed to get to the rest of the
file systems in the system.

This really goes to the question of what is do_emergency_remount()
for.  If the goal is to minimize damage, then you want to keep things
as simple as possible, and to not allow any emergency remounts for any
file system to block.

If the goal is to allow the normal shutdown path to use this because
the userspace code is too lazy to do a proper shutdown of all user
processes, and too lazy to go through all of the mounted file systems
and individually call FIFREEZE, then sure, we could iterate over the
file systems and call freeze_fs() in kernel code.  But I'm not really
sure I see the point......

> That ensures the filesystem is in a (more) consistent state when force
> remount-ro is called (i.e. which doesn't block or return an error if there
> are writers on the filesystem).  

Right, but if the kernel is calling freeze_fs(), freeze_fs() might
block, and then what would we do?

				- Ted