Google Is Exploring Potentially Using Btrfs In Android

[doublez13]

Isn't that just an issue with the BTFS driver though not BTFS itself?

I'm a HUGE btrfs supporter, but there are a few areas of its on disk format that have made devel a little harder.

[pal666]

Now, contribute to bcachefs instead, and use that.

unlike you, they are not idiots

[pal666]

There are no benefits of using btrfs on a mobile phone or tablet compared to ext4.

i'm pretty sure for you there are no benefits of using phone in the first place

[R00KIE]

BTRFS as a COW filesystem is suppose to be more "flash" friendly. The snapshots are definitely a killer feature even for a mobile phone (which resemble a desktop): think about reconfigure the system to a old "configuration", or providing an old configuration as fallback if an upgrade fail....

Try installing a linux distro on a slow flash drive with btrfs and use it for some time. Try the same but use f2fs then come back and tell me if you still want btrfs in a phone. There is also the question of which is going to be more reliable recovering from a dirty shutdown after a battery runs out of charge.

Also don't forget that btrfs as been baking for so long and it isn't ready yet, if anything they could throw some more developers at f2fs and improve whatever needs improvement and fix whatever corner cases that need to be fixed.

[waxhead]

filesystem corruption shouldn't brick the device. Think about it, if the device was bricked from bad software, then it would be bricked before they flash it at the factory. In essense, dead before being born.

I think that starshipeleven said it all, but imagine if you run ...yeah let's say Windows just for the hell of it on a single drive with NTFS. If the NTFS filesystem gets corrupted you essentially brick the operating system and require a reinstall rendering the (otherwise still physical fine hardware) useless since nothing runs on it. Think about that!
BTRFS on the other hand duplicate metadata (and data if you ask it to) on a single device, so in case you have a bitflip at the right spot BTRFS can recover transparently which is really what BTRFS is all about for me: ensuring your data is correct!

[MartinK]

It's working fine for Sailfish. Apart from that, you've all the benefits of the desktop : compression, subvolumes, snapshots.

No - it isn't. It was indeed used in the original Jolla phone released in November 2013 but unlike other cutting edge technologies, such as Wayland, it turned to be a big problem:

• horrendous issues with free space reporting and availability due to metadata block exhaustion on the fairly small storage on the phone (16 GB)
• general stability & data corruption issues due to the need to use old (Android) kernel & no real possibility to use a newer version from a more recent kernel that might have less bugs
• btrfs balance that might take days to finish and/or would still fail to free any space for metadata blocks - sometimes it would also crash in the middle of a balance run
• impossible to update factory reset snapshots so users who do hard resets have to do a hard reset have to apply many consecutive updates to get to the current "patch level" - and hope no intermediate update fails

Some of the issues faced by Jolla 1 users thanks to btrfs:

Root and home disks full and causing various problems
btrfs balance crashes
[problem] phone laggy and apps crashing [answered]
[Bug] btrfs: ERROR: unable get label Inappropriate ioctl for device
btrfs - phone bricked?
[1.1.7.24] Never ending balance

As a result of this debacle all Sailfish OS devices after the original Jolla smartphone (Jolla C, Intex Aquafish, Jolla Tablet, various community ports to ex-Android devices, etc.) use EXT4 on top of LVM with a simple 2 LV (Logical Volume) layout (rootfs & home), as can be seen for example in this factory recovery script.

Also as you can see from the script the recovery update problem has also been solved - there is now a separate recovery partition that holds recovery archives with content for rootfs & home, which can easily replaced with updated archives as needed. The new factory reset then works as follows:

• drop the current LVM VG (Volume Group)
• create a new one
• create a rootfs and home LVs
• unpack the recovery archives to rootfs & home respectively (already contains the EXT4 filesystem)
• resize the filesystem to fill the LV size
• reboot

[MartinK]

It's working fine for Sailfish. Apart from that, you've all the benefits of the desktop : compression, subvolumes, snapshots.

No - it isn't. It was indeed used in the original Jolla phone released in November 2013 but unlike other cutting edge technologies, such as Wayland, it turned to be a big problem:

• horrendous issues with free space reporting and availability due to metadata block exhaustion on the fairly small storage on the phone (16 GB)
• general stability & data corruption issues due to the need to use old (Android) kernel & no real possibility to use a newer version from a more recent kernel that might have less bugs
• btrfs balance that might take days to finish and/or would still fail to free any space for metadata blocks - sometimes it would also crash in the middle of a balance run
• impossible to update factory reset snapshots so users who do hard resets have to do a hard reset have to apply many consecutive updates to get to the current "patch level" - and hope no intermediate update fails

Some of the issues faced by Jolla 1 users thanks to btrfs:

Root and home disks full and causing various problems
btrfs balance crashes
[problem] phone laggy and apps crashing [answered]
[Bug] btrfs: ERROR: unable get label Inappropriate ioctl for device
btrfs - phone bricked?
[1.1.7.24] Never ending balance

As a result of this debacle all Sailfish OS devices after the original Jolla smartphone (Jolla C, Intex Aquafish, Jolla Tablet, various community ports to ex-Android devices, etc.) use EXT4 on top of LVM with a simple 2 LV (Logical Volume) layout (rootfs & home), as can be seen for example in this factory recovery script.

Also as you can see from the script the recovery update problem has also been solved - there is now a separate recovery partition that holds recovery archives with content for rootfs & home, which can easily replaced with updated archives as needed. The new factory reset then works as follows:

• drop the current LVM VG (Volume Group)
• create a new one
• create a rootfs and home LVs
• unpack the recovery archives to rootfs & home respectively (already contains the EXT4 filesystem)
• resize the filesystem to fill the LV size
• reboot

[eigenlambda]

Compression would be good because SD cards are slow and many Android devices have slow internal storage.

The OS needs to reserve more space for itself than it thinks it needs regardless of partitioning scheme because no one wants to tell the user to delete pictures before their OS can install a security update.

[Guest]

They should replace terribly slow, memory and CPU hungry, java based user space first.

[PuckPoltergeist]

I'm a HUGE btrfs supporter, but there are a few areas of its on disk format that have made devel a little harder.

Could you explain this? What areas of the on disk format are problematic?