Re: [PATCH v2] Add support for new compat feature "super_sparse"

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

On Tue, Jan 14, 2014 at 04:21:52AM -0700, Andreas Dilger wrote:
> A few comments on this new patch:
> - I think the name will be confusing to users, especially non-native English
>   speakers. Is it "sparse_super" or "super_sparse" they want?

Yes, good point.  Maybe sparse_super2?  More generally, I don't think
we want most users of mke2fs ever needing or wanting to use these
features.  We can kind of handle this by using "mke2fs -T smr", or
some such, but this is related to something I've been thinking about
for a while, which is a way of collapsing the following from dumpe2fs:

Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize

... into something like this.

Filesystem features:      ext4_default_set needs_recovery


> - I would suspect that group #1 is not the best place to put the backup.
>   For very large filesystems, there is a conflict with the backup group
>   descriptors in group #0 and #1. It would be better to out the one
>   backup in group #3 or something.  I don't think this will be a problem
>   for SMR drives, since they will be so large that this will easily fit inside
>   (or close to) the flex_bg layout of the inode table.

I'm not sure what what you mean by "conflict with the backup
descriptors in #0 and #1"?

One reason why I'm inclined to leave a backup at group #1 is that for
most file systems, sysadmins are trained to know that there is a
backup at -b 32768.  If we change it to be something else, it makes it
a bit harder to find the backup sb, which is a consideration.

Yes, bigalloc does change the offset, but that's actually another
solution I had been looking at for our use case inside google for big
SMR drives.


> - To simplify matters, it makes sense that super_sparse supersedes
>   the sparse_super and meta_bg features. It doesn't make sense
>   to have both. Should it also require flex_bg?  Without it, it is mostly
>   useless. 

Actually, it doesn't supercede meta_bg.  Meta_bg is about where to put
the block group descriptors to allow for 64-bit online resize, such
that the bg descriptor blocks are no longer contiguous.  This is
separate and distinct from the question of which block group have a
superblock and the contiguous (aka "old-style") set of block group
descriptors as backup.

I agree that for the use case of keeping the data blocks contiguous,
it only makes sense to use it with flex_bg; but the file systems
options are largely orthogonal, and it doesn't actually simplify
anything from a code complexity standpoint to require them.  How we
make it easy for users to request a certain set of features is a
different question, and that's where I think ultimately mke2fs's -T
option is going to come in really handy.

					- Ted