>> + if ((sbi->s_mount_opt ^ old_opts.s_mount_opt) & EXT4_MOUNT_NO_MBCACHE) {
>> + ext4_msg(sb, KERN_ERR, "can't enable nombcache during remount");
>> + err = -EINVAL;
>> + goto restore_opts;
>> + }
>
> It appears that this restriction also applies to enabling mbcache during
> remount as well, so the message should be updated? In particular, if
> NO_MBCACHE is currently set but isn't passed during the remount then this
> will always cause the remount to fail. That makes it harder for users to
> just run something like "mount -o remount,ro".
Remount option handling is a bit strange. If an option is not
specified, it is not automatically cleared in sbi->s_mount_opt. So,
once nombcache option is set in the original mount, it is not possible
to clear it. I don't know whether this option handling behavior in
ext4 is deliberate but because of that, the mount -o remount,ro does
not result in a mount failure. The check above is effectively only to
protect against going from not having nombcache option to having
nombcache option, because the opposite is not possible.
Following shows how "debug" option remains set even though it wasn't
specified during remount:
# mount -o debug /dev/sdb /mnt/sdb
# mount | grep sdb
/dev/sdb on /mnt/sdb type ext4 (rw,debug)
# cat /proc/mounts | grep sdb
/dev/sdb /mnt/sdb ext4 rw,relatime,debug,data=ordered 0 0
# mount -o remount,ro /dev/sdb /mnt/sdb
# mount | grep sdb
/dev/sdb on /mnt/sdb type ext4 (ro)
# cat /proc/mounts | grep sdb
/dev/sdb /mnt/sdb ext4 ro,relatime,debug,data=ordered 0 0
