Ask / Submit
4

Why BTRFS and are alternatives possible? [answered]

asked 2015-06-18 11:38:13 +0200

XiliX gravatar image

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?

edit retag flag offensive reopen delete

The question has been closed for the following reason "the question is answered, an answer was accepted" by XiliX
close date 2015-06-19 10:49:34.235819

3 Answers

Sort by » oldest newest most voted
13

answered 2015-06-18 12:27:49 +0200

t-lo gravatar image

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.

edit flag offensive delete publish link more

Comments

1

I think back-porting is unlikely as newer versions of BTRFS rely on newer kernel options

r0kk3rz ( 2015-06-18 12:54:37 +0200 )edit
3

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 +0200 )edit

I think device will crash or drain accu if they load the auto btfs balancer / or do snapshots in future updates to rollback updates

evo3de ( 2015-06-18 13:02:38 +0200 )edit

@t-lo yes, definitely worth investigating. But in order to upgrade the kernel to a new major version they also need to get the corresponding drivers from the chipset manufacturers (e.g. Qualcomm) and I doubt that this will happen...

tad ( 2015-06-18 14:00:24 +0200 )edit

@t-lo, for the JPhone sure, but I think they are going with a different approach for the JTablet. So doing all that work for a single aging device?

r0kk3rz ( 2015-06-18 14:55:12 +0200 )edit
4

answered 2015-06-18 15:00:37 +0200

chemist gravatar image

updated 2015-06-18 15:03:35 +0200

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.

edit flag offensive delete publish link more

Comments

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 +0200 )edit
1

answered 2015-06-18 13:52:26 +0200

juiceme gravatar image

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.

edit flag offensive delete publish link more

Comments

"Never" is a strong word. I had a laptop with a massive 60GB hard drive once. Could BTRFS still do ballancing if 62 out of those 64GB were filled up?

pichlo ( 2015-06-18 13:57:11 +0200 )edit

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 +0200 )edit

So 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 +0200 )edit
2

@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 +0200 )edit
1

Yes, 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 +0200 )edit

Question tools

Follow
2 followers

Stats

Asked: 2015-06-18 11:38:13 +0200

Seen: 927 times

Last updated: Jun 18 '15