main memory in xperia xa2 after flashing sailfish

answered 2019-02-12 21:55:55 +0300

MartinK
18500 ●154 ●178 ●174

You should be able to find a similar issue reported for Xperia X - it's basically the result of Android related partitioning choices which don't really fit to what Sailfish OS requires.

Android vs Sailfish OS storage

• the internal storage is partitioned with GPT into dozens of partitions, generally small and holding stuff like driver blobs, logos, firmware, etc.
• no one really wants to touch the partitioning as that has the potential to brick the device due to hardware not finding the blobs where it expects them (and possibly some of the blobs might not even be redistributable)
• there are only two big partitions, one where the Android OS was and another, generally the biggest one, where Android data partition was
• the Sailfish OS storage architecture requires two partitions
  • one for system recovery images
  • one for a physical volume for the system LVM volume group, which holds the root and home logical volumes
• during a factory reset, the "LVM partition" is wiped, the LVM layout recreated and content of the recovery images from the other partition (one for root and one for home) used to populate the empty logical volumes

And this is where the initial Android storage layout clashes with Sailfish OS requirements. As there are only two bigger partitions, that can't be resized, one needs to be sacrificed for the recovery images, wasting a lot of space that effectively becomes unusable for the user. On my Xperia X the recovery partition has a size of 7.3 GB, but only about 600 MB of that is used.

The other partition (20.7 GB on Xperia X) then needs to hold the both LVM logical volumes - rootfs and home. This creates another problem, as rootfs is where all native applications are installed, but home is where all user data go.

The rootfs vs home size dilemma

1. you make rootfs big and home small, users will complain there is not enough space for their data (possibly less than half of the advertised storage size with a 5 GB rootfs)
2. you make home big and rootfs small, users users might quickly run out of space for installation native applications and might not be able to apply system updates (which might require 500-1000 MB of free space on rootfs)

Jolla has, in my opinion unfortunately, decided to go with option nr. 2, resulting in a small rootfs by default, which even after the initial installation does not have much free space available. For that reason I always make sure after a Sailfish X installation to use LVM tools from the recovery shell to make the home LV smaller and give the rootfs LV a reasoanble size, generally around 5 to 6 GB. Both LVs are formatted with EXT4 so can be easily grown and shrinked as needed.

I really think Jolla should have gone with option nr. 1 - it's much easier to expand the user data storage with a uSD card than to resize the LVM storage layout, especially on a system that has been in use for a long time, as there is a real chance of data loss if you screw some of the commands up. On the other hand I can understand the fear of negative PR due to user complains about low amount of storage available to user data in comparison to advertised device specs. But there is still a real possibility of bad PR later on, when users fill up their tiny rootfs and start facing various issue.

So what can be done about this ?

• resize the GPT layout
  • maybe it won't brick the device after all
  • could be problematic if users want to flash the device back to Android
• span the LVM layout over both bigger partitions (LVM has supported this for decades), store recovery images on an LV, only erase the rootfs and home LVs during factory reset
  • this would "unlock" all the available storage and give the ultimate flexibility for efficient storage allocation
  • in the very unlikely case of LVM itself getting hosed a reflash might be needed due to recovery images stored on LVM itself
• make rootfs bigger by default, at the cost of smaller home
  • this avoids nasty issues later with the potential of annoying some users early on
  • the easiest and lest efficient improvement to implement