https://bugzilla.suse.com/show_bug.cgi?id=1205374 https://bugzilla.suse.com/show_bug.cgi?id=1205374#c12 --- Comment #12 from Stefan Hundhammer <shundhammer@suse.com> ---
(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. -- You are receiving this mail because: You are on the CC list for the bug.