Package: fsarchiver Version: 0.8.7-1+b1 Severity: normal Debian CI testing has uncovered an incompatibility with e2fsprogs 1.47.2-rc1, as can be seen here[1]. The root cause of the failure of the test backup-and-restore-ext4.sh is that the -r option of mke2fs has been removed and replaced with "-E revision=0".
[1] https://ci.debian.net/packages/f/fsarchiver/testing/amd64/54988709/ The reason for this change was to address a user complaint[2], where a user got confused and used -r 0 where they meant to use -m 0, which led to the user creating a file system which (a) doesn't support dates beyond 2038, (b) doesn't support online resizing, (c) is significantly less efficient than modern ext4 file systems, (d) lacks metadata checksumming, making the file system more vulnerable to bit flip errors, (d) doesn't support Posix ACL's or Extended Attributes, and (e) doesn't support SELinux or Apparmor --- among other issues. [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1086603 Now, one perspective might be to say, "Stupid User! No biscuit!!", and just chalk it up to a Problem Exists Between Keyboard and Chair (PEBKAC) failure. On the other hand, the need for revision 0 file systems is only if you care about compatibility with Linux kernels prior to version Linux 1.2 (prior to 1995, or almost 30 years ago), and making it so easy for users to typo by making it a first-class (-r 0) option could be considered an attractive nuisance. After all, unless you are a file system developer trying to debug potential bugs (such as tune2fs -I 256 massively corrupting revision 0 file systems) or are engaged in very serious, hard-core software archeology, there is no real legitimate use for specifying -r 0 on the command line. Hence, the change that I made in e2fsprogs 1.47.2. Unfortunately, fsarchiver seems to be specifying the file system revision on the command line, for example: mke2fs -q -F -b 1024 -L 'Test' -U ae00bd66-0fd1-4852-91ea-a10c139ee156 -I 256 -r 1 -O has_journal,ext_attr,resize_inode,dir_index,^sparse_super2,^fast_commit,orphan_file,filetype,extent,^journal_dev,flex_bg,^meta_bg,^mmp,64bit,^inline_data,^ea_inode,^large_dir,large_file,huge_file,sparse_super,^uninit_bg,dir_nlink,extra_isize,^bigalloc,metadata_csum,^project /dev/loop0 and so the change in the upcoming e2fsprogs 1.47.2 release to address Debian bug #1086603 is going to break fsarchiver. This bug is to open a discussion about the right ways of addressing this failure. I can see a number of options: A) Change fsarchiver to drop specifying the "-r" option to mke2fs. This would solve the problem, but it would mean that fsarchiver would not be able to accurate backup and restore file systems from 3 decades ago. B) Revert e2fsprogs's change to address bug 1086603 and not worry about leaving an exposed, sharp edge to careless users. C) Change e2fsprogs to silently accept mke2fs -r 1, but to fail on -r 0. This solves the Debian continuous integration failure, thus unblocking e2fsprogs, but would cause fsarchiver to fail to be able to restore file systems dating from 3 decades ago. D) Change fsarchiver to retry with -E revision=N, if -r N fails. This works, but adds potential complexity all just to handle file systems dating from 3 decades ago. A lot of this depends on how much you care about supporting pre-historic, antedeluvian file sysetems from the Linux 1.0 era. I could easily just do option C, which would fix the continuous integration bug, but result in fsarchiver failing on really ancient file systems, at least until you implemented option D on your side. What are your thoughts? Thanks, regards, - Ted
