[PATCH RFC 00/28] fs: don't set SB_RDONLY after filesystem errors

[Jan Kara]

On Wed 14-10-26 12:04:08, Andreas Gruenbacher wrote:
> On Wed, Oct 14, 2026 at 12:20 AM Christian Brauner <brauner at kernel.org> wrote:
> > > I'm in favor of this. Just after checking couple of filesystem changes -
> > > won't we be better off by using a generic flag in super_block for this so
> > > that VFS can check for it? Then each filesystem won't have to implement
> > > its own wrapper for simple_fsync(), quota operations, and whatever other
> > > generic operations that need to bail on shutdown filesystem...
> >
> > Do you mean something like?:
> >
> > From 28c97f2142e255eb835d26deb97b00afccfb7c4a Mon Sep 17 00:00:00 2001
> > From: Christian Brauner <brauner at kernel.org>
> > Date: Tue, 13 Oct 2026 21:15:36 +0200
> > Subject: [PATCH] fs: add a generic emergency read-only state
> >
> > The filesystems that stopped setting SB_RDONLY after an error refuse
> > modifications themselves now. Each of them grew the same checks in
> > ->open, ->setattr, ->fsync, ->write_inode, the directory operations, the
> > quota operations and ->reconfigure. Jan suggested a generic flag so the
> > VFS can do that once (cf. [1]).
> >
> > So add SB_STATE_EMERGENCY_RO in a new sb->s_state word. It is only ever
> > set with set_bit() and never cleared so it can be tested anywhere
> > without any ordering against the setter. A filesystem calls
> > sb_set_emergency_ro() where it used to set SB_RDONLY. SB_RDONLY itself
> > stays untouched so freeze_super() and thaw_super() keep seeing a
> > consistent superblock.
> >
> > The VFS then checks it wherever sb_rdonly() gates a write:
> >
> > - __mnt_is_readonly() so mnt_want_write(), opening files for writing,
> >   access(W_OK), nfsd and overlayfs see a read-only superblock
> > - sb_permission() for vfs_create(), vfs_unlink() and friends
> > - notify_change(), rw_verify_area(), vfs_fallocate(), vfs_fsync_range()
> >   and do_page_mkwrite() for files that were opened before the error
> > - reconfigure_super() refuses going read-write
> > - sync_filesystem(), sync(2) and write_inode() don't write anymore
> > - the dquot code doesn't write the quota files anymore and quotactl(2)
> >   refuses to change anything
> > - "emergency_ro" is shown in the mount options, /proc/mounts shows the
> >   superblock as "ro" and statfs() reports ST_RDONLY like they did when
> >   SB_RDONLY was set
> >
> > What reaches the filesystem without passing through the VFS it still has
> > to refuse itself. That's its allocators, its journal, its own writeback
> > and the deletion of unlinked inodes.
> 
> For shared filesystems like gfs2, the concept of an emergency
> read-only state doesn't make sense because in that state (in gfs2
> terms, a withdrawn filesystem), we cannot do any more cluster-wide
> locking and so we cannot allow any more reads, either. Could we define
> the new flag in a way that would allow filesystems to enforce stronger
> guarantees? This would suggest a flag name other than
> SB_STATE_EMERGENCY_RO, though.

The problem is that a lot of local filesystems really want the emergency
read-only state (and not full fs shutdown). So if you want to fully
shutdown the fs on error, either gfs2 has to do it on it's own or we could
introduce another sb state for that. But I think emergency-ro state needs
to stay...

								Honza
-- 
Jan Kara <jack at suse.com>
SUSE Labs, CR