Comment 4 for bug 1601997

One bit of context --- metadata_csum is not enabled by default in the official upstream e2fsprogs.tar.gz file. So with my upstream maintainer hat, I deliberately decided not to enable it by default, and mentioned in the release notes that individual distributions should decide whether they wanted to enable it. So with the upstream e2fsprogs tarball, the user can still request metadata_csum by asking for it explicitly: mke2fs -t ext4 -O metadata_csum.

With my *Debian* maintainer hat on (well, with some egging on with my upstream maintainer persona :-), I decided to enable metadata_csum by default so that in the testing and unstable branches, metadadata_csum checking would get some additional exposure, and hence testing. This gambit has worked. There have been a number of bug between 1.43 and 1.43.3 that were fixed because they were reported by Debian users. Whether I will continue leaving metadata_csum enabled right before Debian Stretch goes into final lockdown for the Debian Stable release is not something I have decided, but so far the bug report rate has been positive.

Ubuntu has apparently adopted the Debian enablement of metadata_csum by default, because it's based on the Debian 1.43.3-1 package. However, there may be some differences between Ubuntu and Debian --- the average technical sophistication of a Debian vs. a Ubuntu user, compatibility constraints with Ubuntu LTS, etc. --- that may drive a different decision with respect to mke2fs's *defaults*.

It would be good if a decision is made explicitly by Ubuntu / Canonical to decide what best makes since for Ubuntu. If you decide that Ubuntu 16.10 is a community distro, and you want to help me test metadata_csum, that's great. I have had some experiences with less-than-savvy Ubuntu users who really struggled with filing a useful bug report and participating in root causing a bug.