backport btrfs ssd mount option fix

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1740143

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

This backport request does not miss anything. Also, the apport-collect 1740143 doesn't seem to do anything after opening this bug page in ELinks.

> On 27 Dec 2017, at 12:45 AM, Vasya Pupkin <email address hidden> wrote:
>
> This backport request does not miss anything. Also, the apport-collect
> 1740143 doesn't seem to do anything after opening this bug page in
> ELinks.

The change is substantial, can you ask the patch author and BTRFS maintainers if it’s a good idea to backport it to stable Linux?

Apparently the original patch didn’t send for linux stable branch.

>
> ** Changed in: linux (Ubuntu)
> Status: Incomplete => Confirmed
>
> --
> You received this bug notification because you are subscribed to linux
> in Ubuntu.
> https://bugs.launchpad.net/bugs/1740143
>
> Title:
> backport btrfs ssd mount option fix
>
> Status in linux package in Ubuntu:
> Confirmed
>
> Bug description:
> Hello,
>
> It appears that all kernels before 4.14 had a problem with btrfs ssd
> mount option. According to
> https://btrfs.wiki.kernel.org/index.php/Gotchas#ssd_mount_option, it
> has a negative impact on usability and lifetime of modern SSDs. Since
> it is enabled by default when SSD is detected, it affects all systems
> with SSD drives. Please backport this commit to normal and HWE
> kernels:
> https://github.com/torvalds/linux/commit/583b723151794e2ff1691f1510b4e43710293875
>
> ProblemType: Bug
> DistroRelease: Ubuntu 16.04
> Package: linux-image-generic 4.4.0.104.109
> ProcVersionSignature: Ubuntu 4.4.0-104.127-generic 4.4.98
> Uname: Linux 4.4.0-104-generic x86_64
> AlsaDevices:
> total 0
> crw-rw---- 1 root audio 116, 1 дек 17 10:50 seq
> crw-rw---- 1 root audio 116, 33 дек 17 10:50 timer
> AlsaVersion: Advanced Linux Sound Architecture Driver Version k4.4.0-104-generic.
> AplayDevices: Error: [Errno 2] No such file or directory: 'aplay'
> ApportVersion: 2.20.1-0ubuntu2.14
> Architecture: amd64
> ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord'
> AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
> CurrentDmesg: Error: command ['dmesg'] failed with exit code 1: dmesg: read kernel buffer failed: Operation not permitted
> Date: Tue Dec 26 18:57:10 2017
> InstallationDate: Installed on 2011-04-14 (2448 days ago)
> InstallationMedia: Ubuntu-Server 10.04.2 LTS "Lucid Lynx" - Release amd64 (20110211.1)
> MachineType: To Be Filled By O.E.M. To Be Filled By O.E.M.
> PciMultimedia:
>
> ProcFB: 0 nouveaufb
> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-104-generic root=UUID=c7605446-0bf3-11e7-bfa0-f91abd974ce1 ro quiet bootdegraded=true
> RelatedPackageVersions:
> linux-restricted-modules-4.4.0-104-generic N/A
> linux-backports-modules-4.4.0-104-generic N/A
> linux-firmware 1.157.14
> RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
> SourcePackage: linux
> UpgradeStatus: Upgraded to xenial on 2016-07-30 (513 days ago)
> WifiSyslog:
>
> dmi.bios.date: 02/20/2008
> dmi.bios.vendor: American Megatrends Inc.
> dmi.bios.version: P1.40
> dmi.board.name: 4Core1333-eSATA2.
> dmi.chassis.asset.tag: To Be Filled By O.E.M.
> dmi.chassis.type: 3
> dmi.chassis.vendor: To Be Filled By O.E.M.
> dmi.chassis.version: T...

> Apparently the original patch didn’t send for linux stable branch.

I don't know exactly what you mean, but 4.14 kernel has this patch. It's easy to verify by changed messages ("enabling ssd optimizations" vs "enabling SSD mode").

> can you ask the patch author and BTRFS maintainers

I'm not sure how to ask BTRFS maintainers and why I would do so, because patch description suggests that it should be backported and has notes about it:

    Backporting notes

Notes for whoever wants to backport this patch to their 4.9 LTS kernel:
* First apply commit 951e796 "btrfs: drop the nossd flag when
  remounting with -o ssd", or fixup the differences manually.
* The rest of the conflicts are because of the fs_info refactoring. So,
  for example, instead of using fs_info, it's root->fs_info in
  extent-tree.c

> On 2 Jan 2018, at 9:06 PM, Vasya Pupkin <email address hidden> wrote:
>
>> Apparently the original patch didn’t send for linux stable branch.
>
> I don't know exactly what you mean, but 4.14 kernel has this patch. It's
> easy to verify by changed messages ("enabling ssd optimizations" vs
> "enabling SSD mode”).

It doesn’t have “Cc: <email address hidden> <mailto:<email address hidden>>”.
Generally important fixes will also send to the stable mailing list, so Linux stable (4.4, 4.9 and 4.14 in this context) can pull it in.

>
>> can you ask the patch author and BTRFS maintainers
>
> I'm not sure how to ask BTRFS maintainers and why I would do so, because
> patch description suggests that it should be backported and has notes
> about it:
>
> Backporting notes
>
> Notes for whoever wants to backport this patch to their 4.9 LTS kernel:
> * First apply commit 951e796 "btrfs: drop the nossd flag when
> remounting with -o ssd", or fixup the differences manually.
> * The rest of the conflicts are because of the fs_info refactoring. So,
> for example, instead of using fs_info, it's root->fs_info in
> extent-tree.c

I am not a native english speaker, but from what I can understand, it’s more like a caveat instead of a recommendation.

>
> --
> You received this bug notification because you are subscribed to linux
> in Ubuntu.
> https://bugs.launchpad.net/bugs/1740143
>
> Title:
> backport btrfs ssd mount option fix
>
> Status in linux package in Ubuntu:
> Confirmed
>
> Bug description:
> Hello,
>
> It appears that all kernels before 4.14 had a problem with btrfs ssd
> mount option. According to
> https://btrfs.wiki.kernel.org/index.php/Gotchas#ssd_mount_option, it
> has a negative impact on usability and lifetime of modern SSDs. Since
> it is enabled by default when SSD is detected, it affects all systems
> with SSD drives. Please backport this commit to normal and HWE
> kernels:
> https://github.com/torvalds/linux/commit/583b723151794e2ff1691f1510b4e43710293875
>
> ProblemType: Bug
> DistroRelease: Ubuntu 16.04
> Package: linux-image-generic 4.4.0.104.109
> ProcVersionSignature: Ubuntu 4.4.0-104.127-generic 4.4.98
> Uname: Linux 4.4.0-104-generic x86_64
> AlsaDevices:
> total 0
> crw-rw---- 1 root audio 116, 1 дек 17 10:50 seq
> crw-rw---- 1 root audio 116, 33 дек 17 10:50 timer
> AlsaVersion: Advanced Linux Sound Architecture Driver Version k4.4.0-104-generic.
> AplayDevices: Error: [Errno 2] No such file or directory: 'aplay'
> ApportVersion: 2.20.1-0ubuntu2.14
> Architecture: amd64
> ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord'
> AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
> CurrentDmesg: Error: command ['dmesg'] failed with exit code 1: dmesg: read kernel buffer failed: Operation not permitted
> Date: Tue Dec 26 18:57:10 2017
> InstallationDate: Installed on 2011-04-14 (2448 days ago)
> InstallationMedia: Ubuntu-Server 10.04.2 LTS "Lucid Lynx" - Release amd64 (20110211.1)
> MachineType: To Be Filled By O.E.M. To Be Filled By O.E.M.
> PciMultimedia:
>
> ProcFB: 0 nouveaufb
> ProcKernelCmdLine...

What I am saying is that this patch is already in 4.14 kernel, I verified that myself. Which means it was already pulled into stable branch. Now it needs to be backported.

Hi, patch author here. You can ask BTRFS maintainers by mailing to the <email address hidden> mailing list. Also, the patch author email address is in the commit itself, for quick questions. :-)

I just stumbled across this ubuntu issue while being bored and reading https://wiki.debian.org/Btrfs where it's linked.

If you're using btrfs, I would personally not recommend using a linux 4.4 kernel, but at least 4.9 and preferably 4.14. The btrfs project does not really have enough resources to properly manage tracking and sorting out fixes and updating older kernels than the latest LTS. The latest LTS (4.14 now) has the highest chance of getting important fixes, for all other versions it depends on the knowledge and decisions of the patch author what happens. (By the way, this is also the reason Redhat dropped btrfs support: if you don't really know what you're doing (which means investing in having a bunch of serious btrfs developers in your team) then trying to selectively backports things becomes a real mine field quickly.)

Aside from that, the "has a negative impact on usability" is certainly true, and including this change in kernels < 4.14 that are used by Joe Average who wants to use btrfs is certainly useful.

Backporting this one is not risky, the change doesn't bite much. Apart from the mount option behaviour change that's mentioned (which can either be picked or ignored) the old code has pretty much been there since 2008.

Disclaimer: I'm a Debian user, so I don't follow ubuntu kernels closely.

When looking at...
https://wiki.ubuntu.com/Kernel/FAQ#Kernel.2FSupport.Ubuntu_Kernel_Support

...I would recommend btrfs users to just move to Ubuntu 18.x.