Update btrfs from 3.16 to 3.19 + incorporate patches [Maybe related to update issues]

asked 2015-09-11 16:30:54 +0200

CLR64
1019 ●14 ●27 ●35

updated 2015-09-11 18:24:01 +0200

In the context of the update issues I personally find interesting (as annoying as they are), I considered some possibilities and investigated some technologies. I made a post in the previous sailfish update 1.17 release notes before: https://together.jolla.com/question/98953/release-notes-117-bjorntrasket/?answer=105643#post-id-105643

Btrfs still is a new file system known to be unstable and and having bugs. It looks like it never got updated after the initial saifish release or at least the earlier sailfish releases. If the printed version is correct it's 3.16.

Last month version 4.2 appeared that again fixed a long time appearing problem which causes long/complete hangs on deleting files (deleting files at the end of an update?!) https://bugzilla.kernel.org/show_bug.cgi?id=76421 https://btrfs.wiki.kernel.org/index.php/Changelog#v4.2_.28Aug_2015.29

Another bugfix also can be seen in version 3.17 https://btrfs.wiki.kernel.org/index.php/Changelog#v3.17_.28Oct_2014.29

The question is if there the problems or good reasons to not update the file system to a newer version for a overall stabler system and maybe fixing known issues as a bonus.

Update #1.1 Thanks to g7 and r0kk3rz I now have a better understanding of the version numbers and updating of btrfs. The version numbers always relate to the linux kernel version. The current version 3.16 already was higher then the sailfish used linux kernel (3.4). We can't easily update to 4.2 because its codebase highly uses feature/architecture of the 4.2 linux kernel.

But yet we should be able to update to version 3.19 - no important feature updates has been done - but some bugfixes. Also the patch https://bugzilla.kernel.org/show_bug.cgi?id=76421 for example could be incorporated into the release.

edit retag flag offensive close delete

Comments

I think that switching everything to ext4 + LVM is easier than backporting the new BTRFS to Linux 3.4.

g7 ( 2015-09-11 16:53:30 +0200 )edit

@g7 yes, but it is clumsier solution.

peerchemist ( 2015-09-11 21:11:52 +0200 )edit

@peerchemist may be, but it works well and it's an heavily tested combination.

g7 ( 2015-09-11 21:41:42 +0200 )edit

3 Answers

Sort by » oldest newest most voted

answered 2015-09-11 21:26:20 +0200

Philippe De Swert
7698 ●74 ●88 ●91

We did already synched and then updated the 3.4 kernel to the latest (3.4.108 atm) stable releases. With this a lot of fixes, also for btrfs have come in. Unfortunately updating the kernel to one of the newer versions is no small task, and with the limited resources and other devices we are adding there is really no time to do so. Between kernel versions there are quite a lot of changes, especially in the subsystems btrfs uses. Not to mention all the other subsystems the other drivers touch.

I invite people who think this is an easy task to try it themselves and go ahead. The sources are available so try it ;)

Comments

Thank you for your fast reaction.
Still I am kinda irritated. In my posting I assumed we have btrfs on the codebase of version 3.16 because that's what btrfs --version reports.
Now I know that's not the underlying filesystem - it's the tools version. Still you might have looked the code up to this version.

As of btrfs 3.14 the bug #76421 appears. If btrfs really is more or less on version 3.4 with some small changes this whole request surely is completely without use. Most later bugfixes occur on code that already has been changed and no one knows if this bug or many more unknown bugs exists in this sourcecode or not.

I don't want to overstate this topic. If a system runs it runs.
But maybe the filesystem is part of the known and addressed problem, part of performance issues and freezes the phone has.

CLR64 ( 2015-09-12 02:20:24 +0200 )edit

Another view of the picture.

In the time btrfs has been chosen as the filesystem there were much passion for the new project and love to use new and good technologies. Something now still might and should be there but yet the long term plan is and have to on controllable, maintainable and updatable systems.

If it is not possible to update a new not tested technologies by thousands then use one that is.

Regarding this if you agree to btrfs beeing a problem in the current state I prefer and agree to g7 to change rather earlier than later to ext4.

CLR64 ( 2015-09-12 02:49:37 +0200 )edit

@CLR64 wait, I said that is "easier than backporting BTRFS" but not that's easy :)

Unfortunately you can't change the filesystem with a simple system upgrade, you must reflash the entire phone. I think it's not worth it for Jolla as a company to do something like that, understandably (I guess only hundreds of users are willing to reflash the entire phone just to switch to ext4 + LVM).

This is something that the community should do. Personally I wouldn't potentially trash my daily driver phone in trying such a thing :)

g7 ( 2015-09-12 12:46:22 +0200 )edit

I did not use the wording easy anywhere.
Also they shouldn't do it for jolla1, but for later devices.

CLR64 ( 2015-09-12 13:58:35 +0200 )edit

@CLR64: Unfortunately during the testing period (probably due to reflashing often) the problems we sometimes see with btrfs did not show up. So when they started occuring after sales had started there was no way back. However for the tablet just to be sure we went now to the tried and tested ext4 + lvm solution.

Philippe De Swert ( 2015-09-12 21:58:01 +0200 )edit

answered 2015-09-11 16:38:45 +0200

r0kk3rz

10112 ●108 ●186 ●181

Afaik we cant without an updated kernel, as newer BTRFS relies upon new kernel features.

Newer kernel seems unlikely on the JPhone due to QCom BSP.

edit flag offensive delete publish link

Comments

That is basically a lazy excuse. :-P All the pieces are there (freedreno, oss wlan drivers), it's just a fairly big chunk of integration and testing work that Jolla doesn't seem to want to do (even though it would actually deliver on the "OSS" promise for at least the base system).

mornfall ( 2015-09-11 16:52:46 +0200 )edit

Thank you for the comment. I did not note the relation of the kernel/btrfs version numbers yet. But I am still not sure you can't use a newer brtfs version

Quote of: Do I have to keep my btrfs-progs at the same version as my kernel?

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.

Also if we would have problems to update at least higher version to 3.19 has to be possible

CLR64 ( 2015-09-11 16:58:33 +0200 )edit

@mornfall as much as I would love to see a "freed" kernel, I think that would be realistically impossible. They seem to (understandably) standardize the system to libhybris. It will be an HUGE work to basically re-do the hw adaptation, and for a two-year old device. Even the tablet will use libhybris (and the GPU is a standard Intel one).

For the OSS wlan drivers, it has been said before that that would require re-certification of the phone, so I see that unlikely too, unfortunately.

g7 ( 2015-09-11 17:00:56 +0200 )edit

@CLR64 btrfs-progs contains the userspace applications to manage btrfs filesystem (like the "btrfs" tool we all know and love). The real deal (the driver) is inside the kernel, and it can't be backported because much changed between 3.4 and 4.2.

AFAIK the version of btrfs-progs currently in our Jolla phones (3.16) is still newer than the kernel drivers, and indeed it doesn't work fully: https://together.jolla.com/question/92841/bug-btrfs-error-unable-get-label-inappropriate-ioctl-for-device/

g7 ( 2015-09-11 17:13:37 +0200 )edit

Ok thanks, got that. The filesystem driver is inside the kernel. Anyway yet they should be able to do an update from 3.16 to 3.19 and maybe apply some important patches.

CLR64 ( 2015-09-11 17:22:35 +0200 )edit

answered 2015-09-14 19:13:20 +0200

CLR64
1019 ●14 ●27 ●35

updated 2015-09-14 19:24:16 +0200

I accept the answer Philippe De Swert gave in one of his comments

Unfortunately during the testing period (probably due to reflashing often) the problems we sometimes see with btrfs did not show up. So when they started occuring after sales had started there was no way back. However for the tablet just to be sure we went now to the tried and tested ext4 + lvm solution.

The first time I read about this change in the used filesystem. Good news in terms of a better working tablet/later device I think.
On the other hand it's sad, we have to accept in many parts now that Jolla1 going to get drawbacks (android support, filesystem...) but I guess that's the normal way.
Good to see that future devices should work more stable. Still it would be nice if the btrfs solution on Jolla1 could be bugfixed even a bit more.

edit flag offensive delete publish link

Update btrfs from 3.16 to 3.19 + incorporate patches [Maybe related to update issues]

Comments

3 Answers

Comments

Comments

Question tools

Stats

Related questions

Update btrfs from 3.16 to 3.19 + incorporate patches [Maybe related to update issues]

Comments

3 Answers

Comments

Comments

Question tools

Public thread

Stats

Related questions