Question re: ext4 filesystem in FD64-900 Alpha and 814 [Solved]

[baldronicus]

Thank you to the Fatdog Team and all involved in the release of both Fatdog64-814 and Fatdog64-900 Alpha.
Your efforts are very much appreciated. Thanks again.

Unfortunately one of the items in the Release Notes is leading me to show both my ignorance and paranoia, once again .

Is the LFS patch regarding newer ext4 filesystems being applied in order to access additional features, or because there might be incompatibilities between newer and older ext4 filesystems?

I guess the real basis for the question is if one is likely to be mixing both older and newer ext4 filesystems on the one machine (e.g. sharing data partitions between older and newer distro installations) could one get into trouble with inconsistencies/ failure to read, or write, properly, etc. ?

It is realised that I might be going over the top, since I imagine such a major change would have a lot more discussion (but then I don't really follow things closely).

Please accept my apologies if I am just wasting your time with (what I suspect might be) such a silly question.

Again, thank you for making available all the neat things that go with a Fatdog64 release.

[jamesbond]

Thank you to the Fatdog Team and all involved in the release of both Fatdog64-814 and Fatdog64-900 Alpha. Your efforts are very much appreciated. Thanks again.

You're welcome.

Is the LFS patch regarding newer ext4 filesystems being applied in order to access additional features, or because there might be incompatibilities between newer and older ext4 filesystems?

ext4 filesystems created by newer mkfs.ext4 (found in FD900, and perhaps other Puppies as well) are created by default with some features that bootloaders don't recognise, thus, they will refuse to boot from it. Those features are actually safe (because bootloaders only read from filesystems and never write to it), so the patch allows the bootloaders to recognise these safe features and continue to boot.

Alternatively you can always turn off the features using tune2fs each time you create a new filesystem, but it gets tiresome very quickly.

I guess the real basis for the question is if one is likely to be mixing both older and newer ext4 filesystems on the one machine (e.g. sharing data partitions between older and newer distro installations) could one get into trouble with inconsistencies/ failure to read, or write, properly, etc. ?

No, not at all. The main factor here is the kernel. Newer ext4 features are no readable by old kernels, and then that happens you will know about it (the filesystem can't be mounted). As long as you're using new enough kernels then there is no problem.

The feature that gets enabled by newer e2fsprogs have been supported in the kernel for quite a while now. They are just not usually turned by default, but now they do.

It is realised that I might be going over the top, since I imagine such a major change would have a lot more discussion (but then I don't really follow things closely).

That's just the changes that we inherit from upstream (from the developers of e2fsprogs).

Please accept my apologies if I am just wasting your time with (what I suspect might be) such a silly question.

No questions is silly. There are only silly answers

Again, thank you for making available all the neat things that go with a Fatdog64 release.

You're much welcome. Enjoy, and don't forget to report any bugs, so we can make it better for everyone.

[baldronicus]

Hi @jamesbond . Thank you for the info in your reply. Please accept my apologies for the delayed response, and for that response being tangential to Fatdog64 900 Alpha. Out of curiosity, I thought I would try to get an idea of the bounds of the puppies that could access the newer ext4 filesystems, using Fatdog64 900 Alpha to generate the new filesystem.

It was a very rough attempt, and subsequent to it, I actually thought to check the man pages in Debian 12.0.0-amd64 "Bookworm". If my understanding of the man ext4 page is correct, metadata_csum was available in kernel 3.18, and metadata_csum_seed was available with kernel 4.4 (there was also a warning that there could also be some variations).

Slacko32-6.9.9.9 has a 3.16.43 (i686) kernel and the tune2fs version is 1.43.1 (08-Jun-2016). It did not mount the filesystem, but tune2fs could access the filesystem info (tune2fs in the earlier pups that were tried, couldn't).

Slacko32-7.0 has a 4.4.249 (i686) kernel (if I noted it correctly) and the tune2fs version is, interestingly, 1.43.1 (08-Jun-2016), apparently the same as that in Slacko32-6.9.9.9. Slacko32-7.0 could mount the partition and access the file.

As you had indicated, support has been there for a while.

I am hoping that at least with a rough idea of the bounds, those of us who run some older stuff, as well as the new, can plan things, so we don't get into as much trouble (yeah, sure , in my case ).

[edited to remove some of the waffle and to mention the man page check]

Thanks again for all your advice and assistance, and for the efforts of the Fatdog Team and all involved.

[jamesbond]

@baldronicus, no worries.

For completeness, the "feature" that automatically gets enabled when you make a new filesystem using 900 is "metadata_csum" (and metadata_csum_seed). Apparently this started to make its way to the kernel back in 2012, according to the kernel wiki.

This feature can be turned on and off without any harm for existing filesystems.
To turn it off: tune2fs -O ^metadata_csum /dev/your-disk
To turn it on again: tune2fs -O metadata_csum,metadata_csum_seed /dev/your-disk

Fatdog64 800's tune2fs supports this already and can turn-on/turn-off the feature as well. The only difference between 800 and 900 is that in 900 the feature is enabled by default when you make a new filesystem.