Why is 64bit option always on by default now?

Why is 64bit option always on by default now?

[Dan Arena]

Hello,

I just spent a while troubleshooting a system that wouldn't boot after
reformatting an ext4 filesystem. I finally figured out that it was the
ext4 64bit feature which caused the issue because the board's
bootloader doesn't support it. Tracking why it occurred when doing
mkfs on one system (fedora 23) vs another (fedora 25) I noticed that
fedora 25 now has the 64bit option in the features list for ext4 in
/etc/mke2fs.conf.

Why was it changed from "auto_64-bit_support" which only added the
64bit option if needed when creating a filesystem larger than 16TB, to
now being always on, even when creating a small filesystem?

I was trying to think of why this would be changed from the "auto
64bit" setting, and it came to mind that it may be useful for when you
later want to grow a filesystem to over 16TB. It looks like you can
now add the 64bit option using resize2fs though, so that point isn't
as important. Maybe this wasn't possible before, so it was the better
option. Now that it can be added with resize2fs, do you think it
should be changed back to "auto 64bit"? I realize having to add the
64bit option with resize2fs may prevent live resizing to larger than
16TB, but I don't think that scenario will be very common, so the
extra work of having to do the offline resize2fs isn't a big deal.

While doing some research I read that it also broke compatibility with
a few other things. I am not sure what the best solution is, I was
just surprised how this compatibility-breaking change was made with as
far as I know not much warning to the community or when running the
command or something.

Thanks,
Dan

Re: Why is 64bit option always on by default now?

[Theodore Ts'o]

64-bit support has been around for 7 years (since e2fsprogs 1.41).
And yes, e2fsprogs 1.43 now has the ability to convert a file system
from 32-bit to 64-bit, but this is an inherently dangerous thing to
do, since it requires rewriting the inode table.  If you ever crash or
power fail during the conversion, *boom*, you can lose all or most of
your data.  So the conversion can be used as a short cut where you
back up the whole file system, and then try to convert to 64-bit, and
if it succeeds, then you don't have to do the restore step.  If it
crashes and you lose everything, then you can reformat the file system
and restore from backups.  :-)

In general, I assume that embedded developers are more sophisticated
than users (who will use the mke2fs in the installer to install thier
root file system, which will be a matched set with the bootloader).  I
also can't be responsible for crappy, obsolete bootloader on embedded
devices, some of which have device drivers only available in ancient
BSP kernels using 3.10, etc.

Also, people who care can always edit /etc/mke2fs.conf to adjust the
defaults.

> While doing some research I read that it also broke compatibility with
> a few other things. I am not sure what the best solution is, I was
> just surprised how this compatibility-breaking change was made with as
> far as I know not much warning to the community or when running the
> command or something.

It's documented in the Release Notes.  You're the first person who has
complained.  Part of it is that community distributions have a much
lower threshold of compatibility requirements compared with, say,
enterprise distributions.  Enterprise distribution vendors are free to
edit /etc/mke2fs.conf in their packages if they want to be more
conservative.  Similarly, with Debian, we enabled the meta checksum
feature in the testing distribution precisely so we could get more
users testing the code and submitting bug report.

Community distributions have always been more aggressive --- so in
general, users aren't whining when Fedora 25 ships Wayland which might
have some incompatibilities with hardware and software.  Instead they
are (in general) happy that Fedora is taking an aggressive stance with
Wayland.  Someone has to be first to release software....

	  	      	    	     	     - Ted

Re: Why is 64bit option always on by default now?

[Jan Kara]

On Thu 22-12-16 21:45:37, Ted Tso wrote:
> 64-bit support has been around for 7 years (since e2fsprogs 1.41).
> And yes, e2fsprogs 1.43 now has the ability to convert a file system
> from 32-bit to 64-bit, but this is an inherently dangerous thing to
> do, since it requires rewriting the inode table.  If you ever crash or
> power fail during the conversion, *boom*, you can lose all or most of
> your data.  So the conversion can be used as a short cut where you
> back up the whole file system, and then try to convert to 64-bit, and
> if it succeeds, then you don't have to do the restore step.  If it
> crashes and you lose everything, then you can reformat the file system
> and restore from backups.  :-)
> 
> In general, I assume that embedded developers are more sophisticated
> than users (who will use the mke2fs in the installer to install thier
> root file system, which will be a matched set with the bootloader).  I
> also can't be responsible for crappy, obsolete bootloader on embedded
> devices, some of which have device drivers only available in ancient
> BSP kernels using 3.10, etc.

Just to add some more data, we have actually got similar reports few months
ago for openSUSE once we shipped updated e2fsprogs. And the bootloader they
used (u-boot) does not support 64-bit feature at all. My answer has been
similar to yours - either update the bootloader or change mke2fs.conf in
your setup. There's one guy working on implementing 64-bit support in
u-boot BTW.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: Why is 64bit option always on by default now?

[Jan Kara]

On Wed 04-01-17 11:51:19, Dan Arena wrote:
> Yes, u-boot is what our boards come with too. It looks like 64bit is actually
> implemented in u-boot now, but only as of a few months ago... see http://
> lists.denx.de/pipermail/u-boot/2016-September/266857.html

Yep, probably a result of that guy who took care of the openSUSE report.

> The board manufacturer told me they are looking into adding it... (they just
> have to update u-boot i guess?)

AFAIK that should be enough, yes.

								Honza

> 
> On Jan 4, 2017 11:18 AM, "Jan Kara" <jack@suse.cz> wrote:
> 
>     On Thu 22-12-16 21:45:37, Ted Tso wrote:
>     > 64-bit support has been around for 7 years (since e2fsprogs 1.41).
>     > And yes, e2fsprogs 1.43 now has the ability to convert a file system
>     > from 32-bit to 64-bit, but this is an inherently dangerous thing to
>     > do, since it requires rewriting the inode table.  If you ever crash or
>     > power fail during the conversion, *boom*, you can lose all or most of
>     > your data.  So the conversion can be used as a short cut where you
>     > back up the whole file system, and then try to convert to 64-bit, and
>     > if it succeeds, then you don't have to do the restore step.  If it
>     > crashes and you lose everything, then you can reformat the file system
>     > and restore from backups.  :-)
>     >
>     > In general, I assume that embedded developers are more sophisticated
>     > than users (who will use the mke2fs in the installer to install thier
>     > root file system, which will be a matched set with the bootloader).  I
>     > also can't be responsible for crappy, obsolete bootloader on embedded
>     > devices, some of which have device drivers only available in ancient
>     > BSP kernels using 3.10, etc.
> 
>     Just to add some more data, we have actually got similar reports few months
>     ago for openSUSE once we shipped updated e2fsprogs. And the bootloader they
>     used (u-boot) does not support 64-bit feature at all. My answer has been
>     similar to yours - either update the bootloader or change mke2fs.conf in
>     your setup. There's one guy working on implementing 64-bit support in
>     u-boot BTW.
> 
>                                                                     Honza
>     --
>     Jan Kara <jack@suse.com>
>     SUSE Labs, CR
> 
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR