Re: [PATCH v2 23/54] libext2fs: Support readonly filesystem images

[Theodore Ts'o <tytso@mit.edu>]

On Thu, Mar 19, 2015 at 02:32:37PM -0700, Darrick J. Wong wrote:
> Finish adding the new rocompat feature, "readonly", which marks a
> filesystem image read-only.  This also fixes a bug in Ted's patch to
> add the feature flag; RO_COMPAT_READONLY needs to be kept out of the
> RO_COMPAT supported feature list.

This really goes to the question of how many user space utilities
should be expected to be able to write a read-only file system.  I was
taking the position that the flag was primarily meant for the kernel,
and that it was fair game for e2fsck to repair a corrupted file
system, etc.

I can accept the position that we shouldn't enable applications which
use libext2fs to be able to modify READONLY file systems by default
--- but I'm not really comfortable putting RO_COMPAT_READONLY on
SOFTSUPP and then enabling e2fsck, resize2fs, et. al to manipulate all
SOFTSUPP features.  The original intent of SOFTSUPP was to allow
debugfs to be able to look at a file system which had some feature
that was under development, but where it was *not* yet safe to let
e2fsck to try to handle such a file system.

So if we want to remove RO_COMPAT_READONLY from the RO_COMPAT
supported feature list, we shouldn't add it to SOFTSUPP, but instead
manually enable it for each of the e2fsprogs program where we want to
allow them to work with a read-only file system.  Which begs the
question whether it makes sense to allow e2fsck to repair a corrupted
read-only file system, or to resize a read-only file system, without
first removing the read-only feature flag.  I think the answer is yes,
we should allow it, but it seems you think the answer should be no, at
least for the latter?

   	  	    	   	     - Ted