Revision history [back]

Btrfs, the file system of Jolla, is copy-on-write type fs. This means that every time somdthing is written to the flash, btrfs needs to find new unallocated space to it. There are some internal structures of btrfs that handle that, but one key issue with btrfs and Jolla is btrfs use of 1 GB allocation chunks. It's obvious that 16 GB flash do not have much breathing room of that kind of allocation scheme. This only mattters if you have once filled your device almost full and all available chunks are already allocated. If you then try to write something big to the flash it may fail even fs reports that you have more space left.

This btrfs issue can be addressed simply to run defragment type of fs operation from cli (devel-su):

btrfs bal start /

The problem is that this take a long time, ~ hour or so, and the system load is high meanwhile. It can akso trigger reboot, if system thinks that there are endless loop going on because high system load of the command if not run by lowered priority.

Jolla/Sailfish should have scheduled background job that automatically runs if there are reasons to do that (it can be check out by using other btrfs commands). The system job should run with low priority like with nice settings and only when the phone has been unused sometime with charger connected.

Btrfs, the file system of Jolla, is copy-on-write type fs. This means that every time somdthing is written to the flash, btrfs needs to find new unallocated space to it. There are some internal structures of btrfs that handle that, but one key issue with btrfs and Jolla is btrfs use of 1 GB allocation chunks. It's obvious that 16 GB flash do not have much breathing room of that kind of allocation scheme. This only mattters if you have once filled your device almost full and all available chunks are already allocated. If you then try to write something big to the flash it may fail even fs reports that you have more space left.

This btrfs issue can be addressed simply to run defragment type of fs operation from cli (devel-su):

btrfs bal start /

The problem is that this take a long time, ~ hour or so, and the system load is high meanwhile. It can akso trigger reboot, if system thinks that there are endless loop going on because high system load of the command if not run by lowered priority.

Jolla/Sailfish should have scheduled background job that automatically runs if there are reasons to do that (it can be check out by using other btrfs commands). The system job should run with low priority like with nice settings and only when the phone has been unused sometime with charger connected.

Btrfs, the file system of Jolla, is copy-on-write type fs. This means that every time somdthing is written to the flash, btrfs needs to find new unallocated space to it. There are some internal structures of btrfs that handle that, but one key issue with btrfs and Jolla is btrfs use of 1 GB allocation chunks. It's obvious that 16 GB flash do not have much breathing room of that kind of allocation scheme. This only mattters if you have once filled your device almost full and all available chunks are already allocated. If you then try to write something big to the flash it may fail even fs reports that you have more space left.

This btrfs issue can be addressed simply to run defragment type of fs operation from cli (devel-su):

btrfs bal start /

The problem is that this take a long time, ~ hour or so, and the system load is high meanwhile. It can akso trigger reboot, if system thinks that there are endless loop going on because high system load of the command if not run by lowered priority.

Jolla/Sailfish should have scheduled background job that automatically runs if there are reasons to do that (it can be check out by using other btrfs commands). The system job should run with low priority like with nice settings and only when the phone has been unused sometime with charger connected.

Btrfs, the file system of Jolla, is copy-on-write type fs. This means that every time somdthing is written to the flash, btrfs needs to find new unallocated space to it. There are some internal structures of btrfs that handle that, but one key issue with btrfs and Jolla is btrfs use of 1 GB allocation chunks. It's obvious that 16 GB flash do not have much breathing room of that kind of allocation scheme. This only mattters if you have once filled your device almost full and all available chunks are already allocated. If you then try to write something big to the flash it may fail even fs reports that you have more space left.

This phenonenon may show up is like this bug reoort.

This btrfs issue can be addressed simply to run defragment type of fs operation from cli (devel-su):

btrfs bal start /

The problem is that this take a long time, ~ hour or so, and the system load is high meanwhile. It can akso trigger reboot, if system thinks that there are endless loop going on because high system load of the command if not run by lowered priority.

Jolla/Sailfish should have scheduled background job that automatically runs if there are reasons to do that (it can be check out by using other btrfs commands). The system job should run with low priority like with nice settings and only when the phone has been unused sometime with charger connected.

Btrfs, the file system of Jolla, is copy-on-write type fs. This means that every time somdthing is written to the flash, btrfs needs to find new unallocated space to it. There are some internal structures of btrfs that handle that, but one key issue with btrfs and Jolla is btrfs use of 1 GB allocation chunks. It's obvious that 16 GB flash do not have much breathing room of that kind of allocation scheme. This only mattters if you have once filled your device almost full and all available chunks are already allocated. If you then try to write something big to the flash it may fail even fs reports that you have more space left.

This phenonenon may show up is like this bug reoort.report.

There are excellent thread about al this here.

This btrfs issue can be addressed simply to run defragment type of fs operation from cli (devel-su):

btrfs bal start /

The problem is that this take a long time, ~ hour or so, and the system load is high meanwhile. It can akso trigger reboot, if system thinks that there are endless loop going on because high system load of the command if not run by lowered priority.

Jolla/Sailfish should have scheduled background job that automatically runs if there are reasons to do that (it can be check out by using other btrfs commands). The system job should run with low priority like with nice settings and only when the phone has been unused sometime with charger connected.

Btrfs, the file system of Jolla, is copy-on-write type fs. This means that every time somdthing is written to the flash, btrfs needs to find new unallocated space to it. There are some internal structures of btrfs that handle that, but one key issue with btrfs and Jolla is btrfs use of 1 GB allocation chunks. It's obvious that 16 GB flash do not have much breathing room of that kind of allocation scheme. This only mattters if you have once filled your device almost full and all available chunks are already allocated. If you then try to write something big to the flash it may fail even fs reports that you have more space left.

This phenonenon may show up is like this bug report.

There are excellent thread about al this here.

This btrfs issue can be addressed simply to run defragment type of fs operation from cli (devel-su):

btrfs bal start /

The problem is that this take a long time, ~ hour or so, and the system load is high meanwhile. It jIt can akso trigger reboot, if system thinks that there are endless loop going on because high system load of the command if not run by lowered priority.

Jolla/Sailfish should have scheduled background job that automatically runs if there are reasons to do that (it can be check out by using other btrfs commands). The system job should run with low priority like with nice settings and only when the phone has been unused sometime with charger connected.connected. The balance operation is quite write heavy so the system should not run the task if not necessarily to avoid excessive wear of flash memory.

Btrfs, the file system of Jolla, is copy-on-write type fs. This means that every time somdthing is written to the flash, btrfs needs to find new unallocated space to it. There are some internal structures of btrfs that handle that, but one key issue with btrfs and Jolla is btrfs use of 1 GB allocation chunks. It's obvious that 16 GB flash do not have much breathing room of that kind of allocation scheme. This only mattters if you have once filled your device almost full and all available chunks are already allocated. If you then try to write something big to the flash it may fail even fs reports that you have more space left.

This phenonenon may show up is like this bug report.

There are excellent thread about al this here.

This btrfs issue can be addressed simply to run defragment type of fs operation from cli (devel-su):

btrfs bal start /

The problem is that this take a long time, ~ hour or so, and the system load is high meanwhile. jIt It can akso trigger reboot, if system thinks that there are endless loop going on because high system load of the command if not run by lowered priority.

Jolla/Sailfish should have scheduled background job that automatically runs if there are reasons to do that (it can be check out by using other btrfs commands). The system job should run with low priority like with nice settings and only when the phone has been unused sometime with charger connected. The balance operation is quite write heavy so the system should not avoid to run the task if not necessarily to avoid prevent excessive wear of flash memory.

Btrfs, the file system of Jolla, is copy-on-write type fs. This means that every time somdthing is written to the flash, btrfs needs to find new unallocated space to it. There are some internal structures of btrfs that handle that, but one key issue with btrfs and Jolla is btrfs use of 1 GB allocation chunks. It's obvious that 16 GB flash do not have much breathing room of that kind of allocation scheme. This only mattters if you have once filled your device almost full and all available chunks are already allocated. If you then try to write something big to the flash it may fail even fs reports that you have more space left.

This phenonenon may show up like this bug report.

There are excellent thread about al this here.

This btrfs issue can be addressed simply to run defragment type of fs operation from cli (devel-su):

btrfs bal start /

The problem is that this take a long time, ~ hour or so, and the system load is high meanwhile. It can akso trigger reboot, if system thinks that there are endless loop going on because high system load of the command if not run by lowered priority.

There are also less resource heavy version of that balance operation like:

btrfs bal start -dusage=5 /

which cures many issues we sailors are experiencing and don't take long to accomplish. The background task should favor this if the logic dethttps://together.jolla.com/users/1629/nthn/ects no need to do full balance.

Jolla/Sailfish should have scheduled background job that automatically runs if there are reasons to do that (it can be check out by using other btrfs commands). The system job should run with low priority like with nice settings and only when the phone has been unused sometime with charger connected. The balance operation is quite write heavy so the system should avoid to run the task if not necessarily to prevent excessive wear of flash memory.

Btrfs, the file system of Jolla, is copy-on-write type fs. This means that every time somdthing is written to the flash, btrfs needs to find new unallocated space to it. There are some internal structures of btrfs that handle that, but one key issue with btrfs and Jolla is btrfs use of 1 GB allocation chunks. It's obvious that 16 GB flash do not have much breathing room of that kind of allocation scheme. This only mattters if you have once filled your device almost full and all available chunks are already allocated. If you then try to write something big to the flash it may fail even fs reports that you have more space left.

This phenonenon may show up like this bug report.

There are excellent thread about al this here.

This btrfs issue can be addressed simply to run defragment type of fs operation from cli (devel-su):

btrfs bal start /

The problem is that this take a long time, ~ hour or so, and the system load is high meanwhile. It can akso trigger reboot, if system thinks that there are endless loop going on because high system load of the command if not run by lowered priority.

There are also less resource heavy version of that balance operation like:

btrfs bal start -dusage=5 /

which cures many issues we sailors are experiencing and don't take long to accomplish. The background task should favor this if the logic dethttps://together.jolla.com/users/1629/nthn/ects detects no need to do full balance.balance as nnth ooints out.

Jolla/Sailfish should have scheduled background job that automatically runs if there are reasons to do that (it can be check out by using other btrfs commands). The system job should run with low priority like with nice settings and only when the phone has been unused sometime with charger connected. The balance operation is quite write heavy so the system should avoid to run the task if not necessarily to prevent excessive wear of flash memory.

Btrfs, the file system of Jolla, is copy-on-write type fs. This means that every time somdthing is written to the flash, btrfs needs to find new unallocated space to it. There are some internal structures of btrfs that handle that, but one key issue with btrfs and Jolla is btrfs use of 1 GB allocation chunks. It's obvious that 16 GB flash do not have much breathing room of that kind of allocation scheme. This only mattters if you have once filled your device almost full and all available chunks are already allocated. If you then try to write something big to the flash it may fail even fs reports that you have more space left.

This phenonenon may show up like this bug report.

There are excellent thread about al this here.

This btrfs issue can be addressed simply to run defragment type of fs operation from cli (devel-su):

btrfs bal start /

The problem is that this take a long time, ~ hour or so, and the system load is high meanwhile. It can akso trigger reboot, if system thinks that there are endless loop going on because high system load of the command if not run by lowered priority.

There are also less resource heavy version of that balance operation like:

btrfs bal start -dusage=5 /

which cures many issues we sailors are experiencing and don't take long to accomplish. The background task should favor this if the logic detects no need to do full balance as nnth ooints out.

Jolla/Sailfish should have scheduled background job that automatically runs if there are reasons to do that (it can be check out by using other btrfs commands). The system job should run with low priority like with nice settings and only when the phone has been unused sometime with charger connected. The balance operation is quite write heavy so the system should avoid to run the task if not necessarily to prevent excessive wear of flash memory.

Btrfs, the file system of Jolla, is copy-on-write type fs. This means that every time somdthing is written to the flash, btrfs needs to find new unallocated space to it. There are some internal structures of btrfs that handle that, but one key issue with btrfs and Jolla is btrfs use of 1 GB allocation chunks. It's obvious that 16 GB flash do not have much breathing room of that kind of allocation scheme. This only mattters if you have once filled your device almost full and all available chunks are already allocated. If you then try to write something big to the flash it may fail even fs reports that you have more space left.

This phenonenon may show up like this bug report.

There are excellent thread about al this here.

This btrfs issue can be addressed simply to run defragment type of fs operation from cli (devel-su):

btrfs bal start /

The problem is that this take a long time, ~ hour or so, and the system load is high meanwhile. It can akso trigger reboot, if system thinks that there are endless loop going on because high system load of the command if not run by lowered priority.

There are also less resource heavy version of that balance operation like:

btrfs bal start -dusage=5 /

which cures many issues we sailors are experiencing and don't take long to accomplish. The background task should favor this if the logic detects no need to do full balance as nnth ooints out.

Jolla/Sailfish should have scheduled background job that automatically runs if there are reasons to do that (it can be check out by using other btrfs commands). The system job should run with low priority like with nice settings and only when the phone has been unused sometime with charger connected. The balance operation is quite write heavy so the system should avoid to run the task if not necessarily to prevent excessive wear of flash memory.

EDIT 21-01-2015 upcoming updates will run a btrfs-balance upon system update as mentioned here