...or using a thin pool, if you want to share more potential space between the two ext4 partition on the LVM.

Meaning that no matter what solution was taken, the low available space on older smartphones such as the Jolla1 *is* going to bite the users, no matter what solution Jolla went for back then.

The only difference is the familiarity of power-users when encountering the symptoms and the familiarity of the procedure to get around it :

- running low on normal EXT4 partition above LVM is about the least surprising condition, and is solved by the most straight-forward solution (freeing space by deleting stuff from the partition that got filled up). The only surprising part being *what* is stored onto which partition (android layer mount-binds stuff from home, so deleting apps *from android* will not necessarily free space from root).

- running low on EXT4 over a thinpool would have been a little bit less straight forward (the partition still reports free virtual space, but the thin pool has ran out of provision to assign to this space, so you get error while trying to write files, even if the partition says other wise). That's probably while Jolla has picked the small rootfs instead of fumbling around thinpools: they have been bitten enough by BTRFS and wanted a more straigh forward and simple handling of space.
(Though a GUI reporting the remainning space on the thin pool, instead of simply the partition free space would have helped).
Procedure gets a tiny bit less straight forward: you need to delete stuff (from whichever partition you want, even the wrong one) and then run TIRM / DISCARD on the claimed space to return it back into the thinpool.
(tough some modern filesystems try to auto-trim under some circumstance like freeing large extents. Sailfish X does it).

- running low on available chunks to allocate on BTRFS is about the weirdest, because the filesystem might need to allocate chunks for CoW - overwriting a file *will* consume extra space even if transiently. Or the filesystem might need more chunks for metadata, be unable to allocate one extra and complain even if there is still plenty of free space on the data chunks and thus the partition seeming free.
The procedure isn't also always straight forward, with re-balancing being needed to free chunks which can then be re-allocated in turn.
Or needing to add extra space by adding SDcard partitions to the BTRFS filesystem.

Though modern BTRFS drivers in recent kernel have dramatically simplified this: "free space" now takes into account chunks (but then gives rise to other situations where *deleting stuff* will *decrease* the free space) and auto-balancing helps somewhat.
(My Rasbperry Pi running up-to-date 4.xx kernels has a lot less (=none) problems with BTRFS than Sailfish OS used to have on Jolla 1)




But in the end, the limited space is problematic for Sailfish, not the BTRFS vs LVM vs thinpool solution.

(Never had a problem with my BTRFS uSD card even back on Jolla1. But that one had a tad bit more space...)


The only slightly better solution would have been adding the phone's "Android System" partition to the LVM volume group (in linear mode) which would have added more headroom. But then in turn would have removed the simple factory reset mecanism (plain partition image laying on a plain Android System partition) and put a rather complex one (needing to handle the reset from within LVM itself, meaning that a corrupted LVM will break the reset. See BTRFS snapshot based recovery and corrupted BTRFS problems for an example).

The current "next best" solution, it to get help from a IT geek, and repartition the space differently between the "Android System" and "Data partition", as usually 7G or more are reserved for Android, but recovery only needs about <1G out of that.
Makes it harder to flashback to Android (e.g.: for Warranty handling), but at least you get a bit more free space to play with.