>The largest consequence socially is a bunch of angry users who read > btrfs wiki page which advocates running a matching version of > btrfs-progs for a given kernel version, despite lack of actual hard > coupling.
Although Btrfs wiki recommends us to use the latest version, it doesn't prohibits to use older btrfs-progs than kernel. https://btrfs.wiki.kernel.org/index.php/FAQ#What_version_of_btrfs-progs_should_I_use_for_my_kernel.3F: > Simply use the latest version. > > The userspace tools versions roughly match the kernel releases and > should contain support for features introduced in the respective kernel > release. The minor versions are bugfix releases or independent > updates (eg. documentation, tests). https://btrfs.wiki.kernel.org/index.php/FAQ#Do_I_have_to_keep_my_btrfs-progs_at_the_same_version_as_my_kernel.3F: > No. > > If your btrfs-progs is newer than your kernel, then you may not be > able to use some of the features that the btrfs-progs offers, because > the kernel doesn't support them. > > If your btrfs-progs is older than your kernel, then you may not be > able to use some of the features that the kernel offers, because > the btrfs-progs doesn't support them. > > Other than that, there should be no restrictions on which versions > work together. In addition, Btrfs hasn't added new user-visible features from v4.8 to v4.9. So it's no problem to keep its version as is from the supported-features point of view. > Notwithstanding bug fixes, and people re-reporting bugs against stable > which are known to be fixed in v4.9.1, on normal usage things mostly > use (e.g. one can mount/upgrade/create use current testing btrfs-progs > with v4.9 kernels) > > Excluding tests / documentation updates / refactoring there are: > * removal of using v1 defrag ioctl, and thus enforcing v2 defrag ioctl > (available since v2.6.33 kernel) > * low memory fixes > * many NULL pointer fixes in check/clone/receive If there are known critical problems in v4.7.3, it should be fixed. However, whether these bugs should be fixed by updating to the new version or by backporting the critical bug fixes to the current version is the other problem. > >> $ git log v4.7.3..v4.9.1 --oneline > oneline.txt | wc -l > >> 438 > > > > That's ridiculous, you can't seriously think that's appropriate when > > other packages are being turned down for fewer changes. The anticipated > > kernel version has hardly been a secret. IMHO, it's too big changes in this phase. How about backporting just important bug fix commits? Thanks, Satoru
