Comment # 12 on bug 1205374 from Stefan Hundhammer

> (In reply to Stefan Hundhammer from comment #7)
> > I am not sure what downsides that might have; larger meta data structures
> > probably that consume a little more disk space. Is that really worth the
> > hassle?
> 
> The bigger issue for me is backward compatibility

AFAIK there is no backward compatibility problem; I could always mount even the
most ancient of filesystems. That has nothing to do with what options are used
for creating new ones. 


> but the larger data structures also play a part on these test installations 
> going on 8G or smaller / filesystems.

If disk space waste is your concern, please have a look at this:

https://github.com/shundhammer/qdirstat/blob/master/doc/Pkg-View.md

and try it on your system, and then consider where disk space is really an
issue. I don't think that filesystem metadata really make an noticeable
difference when so many packages consume so much disk space.



> All my installations to MBR disks are presumptively
> so because they are on old systems with old installations, thus may be
> running old kernels that may not support the newer feature.

ext4 and 64 bit systems have been around for a long time. If you really need to
mount the root filesystem of a more recent distro on a very old one, I don't
think that will be an issue.


> This would be an upstream issue I would think, but it just seems wrong that
> 64bit can be forced when 128bit inode size and/or 1024 byte block size are
> also allowable and applied options.

Please take that discussion up with upstream.


> Better resolution to either add an arbitrary option box to formatting, to
> parallel the one in mounting options, and/or add another tick box for
> disabling the 64bit default. Undoing with tune2fs for me does not constitute
> working.

There is a limit to the exotic scenarios and use cases that we can support.