We have moved to a new Sailfish OS Forum. Please start new discussions there.

Root and home disks full and causing various problems

asked 2014-02-27 13:37:14 +0300

Manatus gravatar image

updated 2016-09-07 19:12:00 +0300

SailfishOS (Äijänpäivänjärvi) and onwards: Jolla has implemented a workaround

Jolla has implemented filesystem checks to their upgrade process. Balance will be run when you are updating your phone to the latest versions of SailfishOS.

This does not fix any issues you may get in between the update releases. It is still a good idea to avoid filling up your phone's own filesystem more than 7 GB, and use sdcard for storing big amounts of data instead. In any situation where you've gone past the 7 GB limit, even temporarily, you should check the btrfs allocation level on your phone and run balance if necessary.

Btrfs-balancer command requires developer mode.

btrfs-balancer allocation

Should the allocation (used) show higher value than 13153337344 bytes, you should run balance operation. Before doing this, make sure you can connect to your phone via SSH.

btrfs-balancer balance

If you've successfully upgraded to SailfishOS or later, this operation is unlikely to take very long time, as your filesystem has been balanced recently during the upgrade.

Problems and notes:

  • Btrfs-balancer's prerequisites seem to be in order now. (Vitaminj found and opened up a bug report regarding btrfs-balance command here: https://together.jolla.com/question/90031/new-btrfs-balance-service-in-114-seems-to-ignore-battery-percentage-gate/
  • Btrfs-balance command is scheduled to run in Tuesdays 3:00am as a service. Unfortunately it does not seem to work. It did in but not in later versions, regardless of whether the phone is in sleep state or not.
  • Below are files introduced with 'btrfs-balancer' command. See also the rest of this article for plain 'btrfs balance' command.





Applicable: SailfishOS (Yliaavanlampi) or earlier

This is a report about btrfs filesystem issue on Jolla device's internal sdcard partition /dev/mmcblk0p28. The device contains /, swap and home mountpoints. This issue manifests itself as inability to write on root and home mounts and their subdirectories. This can happen when there are several gigabytes of free space left on the device. You may only want to write 10 kilobytes change and that too fails. With btrfs usual methods of checking free space on the device do not apply, such as Sailfish OS built in report or commands du or df.

There is no clear indication to the user that btrfs is incapable of writing requested changes on the volume, but many usability problems it causes are very clearly noticeable. Because most of the symptoms are not unique to this issue only, it is mandatory to enable developer mode and have a look at the filesystem status and logs.

It is not known whether this is an unfortunate design feature of btrfs or a bug in btrfs implementation of current kernel. Internal mass memory as small as 16 GB may not simply be big enough for a filesystem as complicated as btrfs. Or at least not if the user saves his/hers data on the same volume in any reasonable amount.

If you have constant stability problems with your phone and suspect you are having this issue, it is best to try and fix it before the situation gets worse. Please note that trying to upgrade or factory reset the device instead may complicate your situation considerably. So far updates or factory reset do not fix the ongoing issue on your device! There is a high probability that this problem is going to be fixed or worked around in coming Jolla updates. See the notes in the end of this article.

If you want to overrule the possibility of btrfs allocation problems on your device, the btrfs fi show command is completely safe to use. See 'How to evaluate the situation' down below.

Unfortunately the actual btrfs balance operation is NOT SAFE. According to Dez's answer in this article, running balance is not safe with current kernel version of Sailfish OS.

Running full balance without filters can cause high CPU and IO loads. This may lead to restarts to sailfish services or something that look like reboots but are only GUI related (green led, black screen). Reboots may happen too if you are very unlucky. Reboots or power cuts during the filesystem operations can cause loss of data and lead to a bricked device, recoverable only by Jolla care with a firmware flasher. However reboot during balance is not "autobrick"; btrfs recovery and balance operations may start and continue after the reboot without problems. This seems to be most often the case.

To keep the balance operation as light as possible running it with balance filter (parameter '-dusage') is highly recommended. With filter CPU and IO load and risks are significantly lower compared to a full balance.

Btrfs balance operation requires enabling developer mode on Jolla phone and some basic experience of working with linux command line. For how to achieve devel-su (eg. root), see this wiki article.

It is vital that you have SSH connection enabled. You cannot do this afterwards if the graphical interface freezes, or your screen turns and stays black just because of high CPU and IO load or crashing services. In addition it would be best that you are familiar with recovery steps using telnet in case that things do not go smoothly.

In no circumstance should you remove the battery during the balance process. You have to cancel the operation or confirm that the operation has finished. Previously enabled and established SSH connection is a way to do it should you not be able to access the terminal window locally on the Jolla phone anymore.

General symptoms

When the user runs out of disk space, at least following symptoms may occur:

  1. Sailfish browser may crash or does not load pages. Back button may stop working.
  2. Messages application crashes
  3. Email application crashes
  4. Any program that wants to write on disk and fails may freeze and crash
  5. Any application database may corrupt while the writes fail
  6. Sailfish user interface freezes, crashes and restarts (green blinking led, blank screen)
  7. Flight-mode does not engage (possibly connman fails to bring interfaces down). Could affect any connection changes.
  8. Connecting Jolla to charger causes GUI crash and blinking green led
  9. Factory reset fails
  10. Serious issues after the factory reset when trying to update the phone back to current level

What happens under the bonnet

In short the thesis is that the shortage of disk space is caused by how btrfs allocates 1 GB chunks of raw space for filesystem use. When no single existing blockgroup is suitable writing a specific change, new 1 GB chunk gets allocated.

When the user fills up his/her /home mountpoint with data, all free chunks get allocated very easily. Of available 14 GB space on Jolla device, it is enough to write only ~9 GB (estimate) data on the device to allocate whole 14 GB of free space. Generally speaking the longer the device has been in use, more likely it is that all space has already been allocated.

When btrfs filesystem does not find suitable blockgroup where to write the data in, and it cannot allocate a new 1 GB chunk, it gives an error that there is no space left. For a regular Jolla phone user this is visible as crashing applications, including the graphical interface of the phone itself.

Chunk allocation size for filesystem metadata is smaller, 256 MB, but on Jolla device this is duplicated and requires 512 MB.

Note that both data and metadata can run out of space separately, yet the error and symptoms are the same. They also allocate blockgroups from the same unallocated pool on internal sdcard of Jolla device. Fully allocated device does not have enough space to allocate a new metadata blockgroup. This is more difficult situation than just with data blockgroups: You may not be able to delete files, as there is no space to mark this change to the metadata, and the filesystem refuses the operation.

According to answer below, posted in November 2013, a minimum unallocated space for the btrfs filesystem should be at least 1.5 GB. That would be 1 GB for data and 256+256 MB for metadata.


(Original question http://comments.gmane.org/gmane.comp.file-systems.btrfs/30047)

For more information about btrfs, including space problems, see:






How to evaluate the situation

Useful commands to evaluate the situation are (run as devel-su):

btrfs fi show
btrfs fi df /
btrfs sub list /

Check also these for errors:

dmesg | less

When 'btrfs fi show' command shows 13.75GB used of 13.75GB for 'devid 1' (see example below), new chunks cannot be allocated anymore and the random problems begin. Depending on what, when and where is written, write either succeeds or doesn't.

[root@localhost nemo]# btrfs fi show
Label: 'sailfish'  uuid: 0f8a2490-53ed-4ff6-ba34-b81df3430387
    Total devices 1 FS bytes used 6.42GB
    devid    1 size 13.75GB used 13.75GB path /dev/mmcblk0p28
Btrfs v0.20-rc1

At this point you should also try copying ~500 MB of files under your home directory mountpoint with a 'cp' command. If the copying fails with disk space errors, you have encountered a situation where btrfs thinks it absolutely cannot use any existing blockgroups, and tries to allocate new ones, no matter what.

Measures to free up raw space

Deleting big files helps freeing up space both in under visible filesystem and in the area of allocated space. However it does not shrink the allocated space automatically. When you run out of space it is recommended to delete several gigabytes of data to make sure that the filesystem has enough space to "breathe".

The method to free up space reserved by unused or sparsely used blockgroups is called 'balancing'. It resembles filesystem 'defrag' operation, but instead of just speeding up the filesystem by regrouping splintered files, balance also frees up space. Classic filesystems do not suffer from space usage problems to the extent of btrfs.

Balance operation can consume more space than what you have available. If you do not free up enough space in existing blockgroups manually, you may run out of space during the balancing operation depicted below.

Btrfs balance command manual can be found here:


Before running the balance operation

  1. Take backups of everything you can't afford to lose.

  2. Close all unnecessary applications. Ensure that network connections work.

  3. Remove any excess files from the device you may have copied on it earlier. Try to free up preferably several gigabytes of space in filesystem.

    • Especially look out for directories with very high amounts of files. It has been observed that these can prolong and cause balance operation to run out of disk space (to stop, not harmful). For instance Android's Tripadvisor can cache tens of thousands of files under its data directory, and btrfs balance operation has hard time going through those with IO-rates as bad as sdcards have. Plain uninstalling Android programs does not help; you have to find and delete files manually.

    • If you are unable to delete files, your problem may be that you are in a chicken-egg situation of running out of metadata space. You can free up metadata space in already used block group by overwriting the data in files you do not need.

      echo > /path/to/yourfile

      After this you can try normal deleting again.

    • If you have previously done a factory reset on your device, you may have old snapshots of the filesystem taking up lots of space. To get rid of these, follow instructions in this case:


  4. The balance operation is heavy on the cpu and mmc and your phone may become unresponsive during the process. Since it can take from 10 minutes to hours, and even days(!), it is preferred to have the phone connected to a computer or directly in mains. Start the process directly through SSH session, so you can see what is happening all the time.

    • If the screen goes blank and you can't wake it up by double tap on the screen or short press of a power button, do not longpress power button or remove the battery from the phone! You would risk losing crucial data or cause bootloop. The phone should work normally when the process is finished. No forced reboots should be needed. Absolutely do not remove the battery!
  5. Open two terminal windows or SSH connections. In a second one you can run dmesg command to see any possible errors during the operation.

  6. As devel-su, at first try to balance any block groups that have 0% or under 5% of space in use. This should be a lot faster operation than full balance. The command will tell you how many chunks were relocated but you can check the result with 'btrfs fi show' too.

    btrfs balance start -dusage=0 /

    btrfs balance start -dusage=5 /

Keep going to bigger -dusage parameter values in increments of 5 or 10 % until you see difference. After each balance operation, check the situation with btrfs fi show. Really it shouldn't be necessary to go higher than 25 %. Run the full balance without -dusage parameter only if previous did not free up enough block group chunks (atleast 1.5 GB).

Since both / and /home reside on the same btrfs volume, you can use 'btrfs balance start -dusage=xx /home' too. The result is the same.

When the balance operation is finished (normally in under an hour), you get the result:

[root@localhost nemo]# btrfs balance start /
Done, had to relocate 13 out of 13 chunks

Now run 'btrfs fi show' again:

[root@localhost nemo]# btrfs fi show
Label: 'sailfish'  uuid: 0f8a2490-53ed-4ff6-ba34-b81df3430387
Total devices 1 FS bytes used 6.42GB
devid    1 size 13.75GB used 10.13GB path /dev/mmcblk0p28
Btrfs v0.20-rc1

As we can see here, with 6.42 GB of actual data balancing can clear up 3.5 GB of raw space for future allocations. You should always have at least 1.5 GB of unallocated disk to spare on the volume 'devid 1'. 1 GB for data and 0.5 GB for next metadata blockgroup.

Cancelling balance operation

If the balance operation runs out of space it ends with an error. In experience this is not destructive. You can clear up more files from the disk and try again.

It has also been observed that if your device reboots during the balance, it is triggered to run automatically after the reboot again.

If the balance operation runs too long you can pause or cancel it with these commands:

btrfs balance cancel /
btrfs balance pause /
btrfs balance resume /

Use another SSH session to run them if you did not start the balance operation as a shell background process.

Please note that you get successful result message from these commands in the original shell window where you started the balance. It may take a minute or two until the balance gets cancelled. If the command is not successful, you get an error message on the same window where tried to do cancel/pause/resume.

Notes and tips

  • According to Nekron's find here and here, Jolla is planning to add a systemd service and scheduler script for btrfs balance in coming updates.

  • To be absolutely certain of the health of the filesystem, it would be best to keep Jolla's internal sdcard as empty as possible, and use only external sdcard for storing lots of space consuming data.

  • Before installing any big Jolla upgrades, it might be wise to clear up lots of free space on disk. Running out of space during the upgrade could cause a reboot loop curable only through the recovery mode and factory reset.

  • When clearing up space before balance, btrfs FAQ recommends clobbering files instead of deleting them by, eg. either:

    true > /path/to/file

    echo > /path/to/file

    This clears up space without causing need for new metadata allocation. This is useful if you are running out of metadata space. Try '-dusage=0' parameter in balance command first, as it deletes all unused block groups.

  • -dusage parameter after start command is useful and a lot faster in situations where you have freed up lots of space by deleting files, and just want to free up unused block groups fast.

  • If you you fail at clearing up enough space for balance via previous methods just keep trying. If nothing else works, you can try Juho's method. It is risky if the phone happens to reboot during the operation.

In case you get "no space left on device" when you are running the balance, you can use the external SD card to get the extra space. Please note that if balance fails when loop device is in use, and you cannot delete it properly, you will end up with devided system partition and your device may not boot anymore. At this stage you cannot factory reset either because factory reset on Jolla depends on btrfs snapshots on now broken filesystem.

dd if=/dev/zero of=/media/sdcard/0000-BDCB/btrfs bs=100M count=5
losetup -v -f /media/sdcard/0000-BDCB/btrfs
btrfs device add /dev/loop0 /

That way the balance can get the needed extra. You can remove the device like this:

btrfs device delete /dev/loop0 /

It might be a good idea to use one liner, as suggested by lpr, to make the process a bit less prone to fail:

btrfs device add /dev/loop0 / && btrfs-balancer balance && btrfs device delete /dev/loop0 /
  • 1 GB chunk allocation size was noted with a device with lots of unallocated space left, while copying a large file (4.6 GB) on the device through ssh.

  • It has been observed with btrfs fi df / that during the balance operation filesystem disk usage on the disk slowly but constantly rises to a 1 GB higher figure than what was the original disk usage. When it reaches 1 GB, the usage drops to original level, only to start rising again. It is assumed that filesystem is moving files between block groups, and the process does not discard old block group until the new block group has been completely written. This makes balance as a process less prone to lose data if the system shuts down, but it is ever more important to have enough free space before starting it.

  • Jolla device does have a recovery mode of its own where you can run Btrfs recovery (option 5 in recovery mode). Do this if you cannot access command line through the phone or SSH: https://together.jolla.com/question/22079/howto-all-pc-users-recover-or-reset-a-device-that-is-stuck-in-boot-loop/

edit retag flag offensive close delete



Ok, now this problem happened second time. It started again with a crashing browser, then GUI going down couple of times with green led. I was able to make one copy of 75 MB file I've used for testing, but after that the filesystem claims that /home is full. Yet df-command clains over 6 gigs of free space. I think many of the problems reported here at together.jolla.com about the phone crashing all the time, and led blinking green, may be related to this same filesystem or mmc device problem.

Manatus ( 2014-03-02 01:27:32 +0300 )edit

In the linked article the problem was resolved by upgrading kernel from 3.2.x to.3.11.x. As Jolla is in running with #Linux kernel 3.4.0 does this suggest that the kernel is maybe too old for reliable btrfs (which is still in heavy development)?

foss4ever ( 2014-03-02 04:35:42 +0300 )edit

Possibly yes. But of course there is a possibility that Jolla could have backported things from newer kernels.

Being just an enthusiast and not knowing kernel development is hard to say what is the current status of btrfs. Discussions two years ago mentioned that autorecovery that seems to be enabled (according to dmesg) could make things worse. But that was then and I expect Jolla devs knew its current status when they chose btrfs for the release version.

Manatus ( 2014-03-02 13:25:52 +0300 )edit

Strange. I got UI reset twice. And my disk space is same strange ..

# btrfs filesystem show 
Label: 'sailfish'  uuid: 0f8a2490-53ed-4ff6-ba34-b81df3430387
        Total devices 1 FS bytes used 3.92GB
        devid    1 size 13.75GB used 13.75GB path /dev/mmcblk0p28
# df -h | grep /dev/mmcblk0p28
/dev/mmcblk0p28        14G  4.1G  9.3G  31% /
/dev/mmcblk0p28        14G  4.1G  9.3G  31% /swap
/dev/mmcblk0p28        14G  4.1G  9.3G  31% /home

And remove rec* snapshots not helped with this ..

Kaacz ( 2014-03-03 19:52:00 +0300 )edit

Thanks Kaacz! What does

btrfs fi df /


Have you ever filled up your internal storage knowingly on Jolla?

I'm suspecting the cause for this problem could be that btrfs tries to increase the btrfs volume size instead of writing on already existing free space. The reasons could vary, starting from trimming to something else. If you haven't ever filled up your device, then that figure has kept rising for other reasons than pure file size.

Manatus ( 2014-03-03 20:14:38 +0300 )edit

11 Answers

Sort by » oldest newest most voted

answered 2015-03-19 22:27:14 +0300

Upp15 gravatar image

I have used my phone very "carefully", i.e. NOT installed wildly all kinds of software. So I have never had more than ~6Gb space used in my internal SD memory. But a few weeks ago I started to notice strange behaviour with some apps I use daily (browser, warehouse): they either didn't start or they closed suddenly without warning.

Then I remembered this article, and decided to do the test. To my shock "btrfs fi show" proved, that I probably had this "disk full" problem, it showed "13.75GiB used". It took me a few days to gather enough courage to start balancing the file system. But finally I did start it following the advice from here, and to my relief - maybe because I really had plenty of free space on the disk - it went without problems.

I did the balance up to "-dusage=70", and the final result is "size 13.75GiB used 7.60GiB", which I thought was enough for now (I didn't really have the guts to go all the way ...).

But c'mon, this is something we shouldn't have to do as "consumers" ! How can you explain to a "common man", that "your phone needs a reorg to it's file system, please start your terminal", when there is really less than half of the space used !?

edit flag offensive delete publish link more


That's the payback for ability of factory reset.

Odorobo ( 2015-03-20 09:49:25 +0300 )edit

Why is Jolla using btrfs filesystem in the first place? It seems terrible. You are right, you can not tell a regular consumer to start balancing their filesystem or that half of their mem card is gone because of filesystem. Factory reset has been around for ever in different phone OS, which did not need rebalancing.

alloj ( 2015-03-20 11:57:08 +0300 )edit

if this is meant for mass market, having the user to read this screen pages of post to fix a recurring problem is VERY VERY VERY VERY wrong :S

compared to factory reset, one would definitely gonna hit into this problem much more frequently (c'mon, who resets phone to factory state regularly?).

Jeffrey04 ( 2015-06-01 12:07:53 +0300 )edit

answered 2014-07-11 12:47:10 +0300

Nieldk gravatar image

This seems very likely what happened to my device when I was unable to even enter recovery, finally ending up with a dead battery, which I needed to obtain an external charger that could charge the battery directly. And I hope Jolla reads this article and looks into this.

edit flag offensive delete publish link more


Could be but I think they are stuck with it now. I suppose all this is caused by btrfs bugs, and those are out of their hands excluding kernel updates.

Trying some kind of complete filesystem conversion from btrfs to ext3 or something else straight on the device simply is not doable unless done outside of the system. It is not simple enough process to be done in half an hour that the updates usually takes to install. And while doing so, they would also lose the factory reset option since it is based on btrfs itself.

This all leads to another story where you have already been playing your part. ;)

Manatus ( 2014-07-11 16:22:35 +0300 )edit

answered 2014-11-05 14:01:28 +0300

DanyZ gravatar image

this thread should have a higher number of votes. i believe it needs the attention of Jolla developers

edit flag offensive delete publish link more

answered 2015-02-04 00:56:26 +0300

Direc gravatar image

Jolla has been working on this and they hope to get it out with update 12.

On the platform level, in this iteration we are working towards the following goals:
*System update improvements (will be utilised for update 12 onward):
-run btrfs balance operation before installing OS update

Source: https://lists.sailfishos.org/pipermail/devel/2015-January/005512.html

edit flag offensive delete publish link more


Yes. Too bad they mention only running it before the upgrade. They do not mention that they would be switching kernels, backporting btrfs changes, or giving users option to run it from the GUI.

It could be that Jolla is just aiming for lesser of two bads:

No btrfs balance = certain malfunctions for a lot of people, or btrfs balance = lesser risk of malfunctions.

With the current experience of running balance on Jolla device, I would go with the risk. Especially when they can advise people first to ensure that they have some 4 GB of free space in filesystem and then let the upgrade process start with btrfs balance with less cpu intensive filter such as -dusage=5 or 15. That alone should ensure that btrfs does not get in the way of upgrade.

Manatus ( 2015-02-04 08:26:26 +0300 )edit

I think running balance automatically before OS update is clearly the Right Thing and considering updates are released every few months or so, filesystem doesn't get too cluttered. I hope balance gets its own menu item in Sailfish Utilities app, too, for us more advanced users!

Not making either of those reality is quite obviously the Wrong Thing.

About backporting and upgrading; I'm absolutely certain that making major version jump both in kernel and btrfs versions would present a ton of regressions and new bugs. I vote for patching and conservative backporting, as in, fixing the problem at hand by focusing on the problem. Small changes, less breakage!

Direc ( 2015-02-04 19:07:54 +0300 )edit

answered 2014-11-05 21:18:11 +0300

Andrwe gravatar image


I've moved all Android app data to SD card by following this how-to. Because of that I just had to run btrfs balance start / as my filesystem had enough free space left.

Maybe that helps others preventing or delaying the issue.

Regards, Andrwe

edit flag offensive delete publish link more


I agree. Moving the android files to external sdcard is pretty much the best solution to steer clear of this issue. You can also add space from sdcard to Sailfish side of things too on the same go.

Details also here: https://together.jolla.com/question/40802/how-to-format-your-usd-card-to-btrfs-and-share-space-with-android/

Manatus ( 2014-11-06 00:23:13 +0300 )edit

answered 2016-06-22 13:19:25 +0300

OsoPardo gravatar image

updated 2016-06-22 13:39:26 +0300

Wow...for me that was the backup procedure that put me in that hell...couldn't even delete files anymore...

After trying so many things, the trick with "dd if=/dev/zero of=/media/sdcard/0000-BDCB/btrfs bs=100M count=5" saved my ass but you have to reboot after "btrfs device delete /dev/loop0 /", without reboot, as soon as /dev/loop0 is deleted, you'll get back to "no space left on device" whereas btrfs-balancer allocation will show lot of space (69% allocated for me, btrfs-balancer refused to balance for more)

Giving how hard to get out that nightmare I can't believe there is no fail-safe or even warning to prevent that situation

It's always good to win a battle against the machine but there is not way I'll recommend that bloody sailfish OS to people without sysadmin or linux nerd background...(And despite all this, I still love it...)

edit flag offensive delete publish link more


Yeah, I don't understand why Jolla has always been silent on this very serious issue. They assume that all their customer are linux cli users with knowledge of btrfs and/or visiting TJC regularly :/

Fortunately the next Sailfish devices (if some come out one day) will use ext4, so we might be able to start recommending Sailfish to non tech friends, I hope.

Sthocs ( 2016-06-22 14:11:34 +0300 )edit

Dude, why are you even still on this old version of Sailfish?

bennypr0fane ( 2016-06-27 11:30:52 +0300 )edit

I'm using last version of Sailfish OS :, Taalojärvi

OsoPardo ( 2016-06-27 12:06:10 +0300 )edit

Aw, this finally happened to me too yesterday while trying to start the "optimizing process" before installing update 2.0.5. The btrfs allocation was 90% before, then increased to 96%, everything started to be sluggish, the second after I had the "No space left on device" message while trying to balance.

Many thanks to @Juho for his instructions! Little question: Do we need to do a losetup -d /dev/loop0 before removing the file /media/sdcard/0000-BDCB/btrfs? I assume that it's safe to delete after rebooting anyway.

Sthocs ( 2016-11-23 15:44:47 +0300 )edit

answered 2014-10-20 14:15:39 +0300

Is there a way to do this without devel-su, which requires the use of developer mode? I am sure there are a lot of users who don't enable this but they will sooner or later hit this problem. Why is btrfs chosen at the first place? Would other file systems (for instance ext2/3/4) suffer the same problem too?

edit flag offensive delete publish link more



It probably comes down to Qualcomm; StsKeeps once said that it helps bunching up partitions needed by Qualcomm Android hardware. It also makes possible to offer users a recovery-functionality without distributing flash-images. Unfortunately latter is not very good option, as doing recovery can make the situation worse to recover from.

Ext would not suffer from this problem.

Manatus ( 2014-10-20 17:58:31 +0300 )edit

except the recovery thing doesn't really work.... if i am not mistaken, if i brick my device, the only way i can get it fixed is to send it to jolla care :S

Jeffrey04 ( 2014-10-21 12:02:13 +0300 )edit

answered 2014-12-03 23:42:52 +0300

richie gravatar image

Hello, I think I have the same issue. My web browser always crashes if I attempt to open the bookmarks immediately after starting the browser. I have to wait a few seconds for the last tab to load before opening bookmarks.

The output of btrfs fi show for me is

Label: none  uuid: 3f973af4-9591-44f7-a011-b9cb9b36d2ee
Total devices 1 FS bytes used 7.35GB
devid    1 size 58.56GB used 14.04GB path /dev/mmcblk1
Label: 'sailfish'  uuid: 0f8a2490-53ed-4ff6-ba34-b81df3430387
Total devices 1 FS bytes used 6.54GB
devid    1 size 13.75GB used 13.75GB path /dev/mmcblk0p28

So the sailfish shows size 13.75GB used 13.75GB, which I take it means I have this issue too?

Also, my microsd card also has the same devid 1 as sailfish. Is that right? And how would I ensure I only balance the internal storage and not the microsd?

Finally before I use the commands here to fix this, does a successful balancing of the btrfs filesystem cause any damage, i.e. a serious reduction in life of the internal storage?


edit flag offensive delete publish link more


Yes, you may have it. 13.75GB/13.75GB should not automatically mean problems, but the chances are high.

Btrfs filesystem can span over several devices. Devid 1 means that these two separate btrfs filesystems have only one device each.

I have not yet bumbed into a way how to recognise different filesystem paths via btrfs-command parameters. You cannot target it directly on device, as mentioned it can span several devices. So I've used mount-command to figure out where those /dev/mmcblk* devices are mounted at. Then you can point the command to that mountpoint and it balances that filesystem (and device in this case) only.

Full balance without filters most likely causes some wear on storage. Delete couple of gigabytes of big files on internal storage, and use btrfs balance start -dusage=0 / to balance internal storage without risk of wear and tear. That only removes completely unused 1 GB block groups without moving files around.

Also filter '-dusage=5' should cause only minor wear (plus is a lot faster than full balance without any filters).

Manatus ( 2014-12-04 00:50:29 +0300 )edit

I had exactly the same problem with browser, had to wait until current page loads / timeouts. It disappeared completely after balance. devid is id of device in particular filesystem: each filesystem can have more than one device assigned. btrfs balance finds filesystem to balance by mount path, so you won't balance microSD if you don't want to. Try to run command that @Manatus recommends, be sure to free several GB before that. If command reports that 0 blocks were relocated, try -dusage=5, if still 0 blocks, increase it to 10, etc. It can go up to 100, which is mostly the same as full rebalance (and that is very slow).

butler ( 2014-12-04 01:19:14 +0300 )edit

Just as a comment: I also had this problem with Tahkalampi, but it's gone with Vaarainjärvi. My btrfs was never close to being full, so I assume this might be a different problem. The question of course is, why balancing fixed this for you...

Jolly-Jo ( 2015-02-04 11:52:05 +0300 )edit

answered 2015-06-05 00:58:10 +0300

Hecraps gravatar image

Hi everyone ! I'm really tired of my Jolla at this moment, since two days I got lots of problem with. It was slow as hell, android app don't launch (they load during 5 minutes and close), Sailfish app are laggy, can't install any sailfish app, can't remove android app. Reboot my phone, and find that all my text have disappeared but after 2 other reboots they came back ! So I decided to investigate about btrfs. First of all, I never touched any linux OS, so BTRFS is pretty new to me, I didn't know that the flash disk was running under that format. And I also discovered lots of complain about it and about a certain "balance". I knew that my phone was pretty low on memory, because I couldn't find a way to transfer all my videos and pictures on my PC because W8.1 was unable to find the drivers... So I finally did, and made some space. I'm at 9.85Go of occupied space on the disk and don't know where does come all that data because I don't have any music or pictures now. I decided to make a quick diag as written in this thread and made a btrfs fi show, and discover that famous 13.85Go/13.85Go. Made a quick balance with -dusage=0...5...10 I manage to transfer 17 from 23 chunks. Finally, btrfs fi show brought a new result 10.53Go/13.85Go Relaunch btrfs fi show 5 minutes later because the phone was laggy again => 13.85Go/13.85Go.

Don't know what I can do more, my phone is still laggy as hell, don't know where does all this data is stored on the disk (it's impossible that I have 9.85Go of data, I have even deleted the old backup).

Please help me, don't let me in that mess...

edit flag offensive delete publish link more



Hi! If you have used lots of Android apps, you could check command du -hs /opt/alien/sdcard and du -hs /opt/alien/data as 'devel-su'. If they are very big, some android app is using up the space.

Caution: not everything under /opt/alien is android specific; under there is links to actual Sailfish directories too.

Manatus ( 2015-06-05 08:11:01 +0300 )edit

Hi Manatus ! Thanks a lot for you help. You are right, for the sdcard : it's empty (4Ko). But for the alien/data, the phone is almost full with 6.3Go of data. Can I delete the whole Data folder without risk ? (I don't care if I lose all my android app).

Hecraps ( 2015-06-05 10:29:47 +0300 )edit

@Hecraps Please don't delete /opt/alien/data directly. It is risky.

But you can check directories under the data-directory, for instance /opt/alien/date/media. Basically anything under media you can delete without risk. You may lose some data saved in your Android apps though.

Manatus ( 2015-06-05 14:29:18 +0300 )edit

answered 2015-04-12 00:37:49 +0300

Kristjan gravatar image

updated 2015-04-12 00:41:46 +0300

It showed for me:

image description

I did "btrfs balance start" up to 55 and nothing has improved (Android apps still do not work).

What should I do now? Did I do something wrong?? I'm quite confused.

By the way, maybe somebody can tell me how to insert this kind of information not as a picture but as people above have done.

edit flag offensive delete publish link more


It shows that you have 8.60 GB of space reserved for btrfs filesystem, so everything is ok on that regard. If you have problems to get Android apps working, you may have to remove android support and reinstall it (via Jolla Store app).

If that does not help, remove android support again, and then clean up the remnants of android directories. Warehouse has Dalvik cleanup app by Schturman that does this. He also lists commands that his script runs.

The link is here:


Manatus ( 2015-04-12 20:46:50 +0300 )edit

Thanks! It's finally in proper contition again.

Kristjan ( 2015-04-14 23:49:20 +0300 )edit
Login/Signup to Answer

Question tools



Asked: 2014-02-27 13:37:14 +0300

Seen: 30,438 times

Last updated: Sep 07 '16