asked 2015-06-18 11:38:13 +0300
With all the problems surrounding the BTRFS filesystem on our Jolla's i cannot help but wonder: who came up with BTRFS and why?
And is it possible to just trow BTRFS away and reformat the root FS to, for example, EXT4 and reinstall Sailfish?
answered 2015-06-18 12:27:49 +0300
There are issues with Jolla's file system (mostly) not because it's the wrong choice of technology but because the FS tries to solve complicated problems. There are quite a few unique challenges in setting up a phone storage stack. This is by a large part because the Jolla Phone, at the end of the day, is an embedded system that needs to function w/o any regular, capable manual maintenance (contrary to e.g. a server system). While it may be argued that the current situation is not quite up to this goal, I also think that, with a better understanding of BTRFS, we're getting there.
Consequently, there are some quite advanced features in BTRFS that are lacking in EXT4. For instance, you would instantly lose device backup functionality as well as the "reset to factory firmware" - those rely on BTRFS features which you would have to add manually around EXT4. And while I'm not saying that this is impossible (e.g. LVM could do this for you, in a way) I don't see the value in switching one complicated stack for another complicated stack we have no experience with.
While we're at it, I think a better way to handle Jolla FS problems is to focus on back-porting more recent BTRFS releases to the Jolla kernel.
You're right - working around those missing kernel features and maintaining those workarounds for the time being is a lot of work. However since BTRFS is not just a file system for the Jolla phone but also a provider for quite a few phone core features I'd argue that this might be worth investigating.
t-lo ( 2015-06-18 12:58:27 +0300 )editanswered 2015-06-18 15:00:37 +0300
From git commits you can guess that Jolla Tablet will have LVM instead (not sure if it was communicated officially anywhere) - as Jolla1 will not get a newer Kernel any time soon there is a better bet to work with Sailors to find a way to move a device from btrfs to lvm. Although I'd like Jolla to stay with btrfs for various reasons, most otf features of btrfs are missing in ext and cannot even be handled with LVM without getting your hands a little dirty.
Here's LVM on the tablet:
[root@Jolla nemo]# lvm lvscan ACTIVE '/dev/sailfish/root' [3.91 GiB] inherit ACTIVE '/dev/sailfish/home' [49.98 GiB] inherit
and mount says:
[root@Jolla nemo]# mount /dev/mapper/sailfish-root on / type ext4 (rw,noatime,data=ordered) /dev/mapper/sailfish-home on /home type ext4 (rw,relatime,data=ordered)
The kernel is: Linux Jolla 3.10.20 #1 SMP PREEMPT Mon Sep 28 07:34:49 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Do you think it would be possible to recreate the tablet fs on the phone? Would that need a newer kernel?
Andy Branson ( 2015-11-17 11:40:05 +0300 )editanswered 2015-06-18 13:52:26 +0300
As I see it the only problem that BTRFS on Jolla has is the comparatively small size of the drive. To work without hiccups a BTRFS volume needs some operating leeway.
If the mmcblk0 size would be 64G like on N9 for example, there'd never be any problems with the filesystem.
An excellent observation :)
No, of course it would not... but IMHO it is unwise in any sense to fill memory devices to the brim. I never had more than maybe 35G...40G on my N9 and I was thinking of similar use cases here.
What could be a valid solution here is have a bit larger (maybe 32G or so) physical device but only allow user to store a maximum of 16G on it. That might be possible with some filesystem tweaks.
And before you cry it is a terrible waste of space; well so are RAID drives and still people use them :)
juiceme ( 2015-06-18 14:08:50 +0300 )editSo if i get this right i have a 16Gb drive which i can not use to store stuff on because the fs is unable to use all the available space. Please correct me if i am wrong on this but you have to admit it sounds a little silly.
Besides, leaving a part of the storagespace empty is not a solution. It is, at best, a way to cover up the real problem.
XiliX ( 2015-06-18 16:07:13 +0300 )edit@XiliX do you know what happens to ALL (have not seen one that does not do the following) android devices when you fill up the rootfs? Oh you do not even get to fill it up as app-caches do that for you... and dead it is... well the system does not lockup like we experience with Jolla, you will have a dead slow (1input accepted per minute) brick and you will have a really hard time to get a usable device back, here you delete some files, start balancing and everything is fine... android devices usually are never fine again without a factory-reset...oh no that does not work... you need to do a full reset with a desktop computer... (true story bro!) - I am not so firm with btrfs yet but would a quota for @ and @home not solve the device-is-full issue?
chemist ( 2015-06-18 16:25:15 +0300 )editYes, the same thing applies more or less to all filestsrems. All operations are quicker when there is enough leeway on the FS.
BTRFS has very good features which make it suitable for embedded use; it is fast, reliable, minimizes wear of underlaying flash layer, provides snapshot baselining...
All in all good tradeoffs to the fact that it requires some leeway space.
Having quotas could indeed be the solution to not filling it up so tight that balancing becomes impossible.
juiceme ( 2015-06-18 16:52:33 +0300 )editAsked: 2015-06-18 11:38:13 +0300
Seen: 1,036 times
Last updated: Jun 18 '15
