View Single Post
javispedro's Avatar
Posts: 2,355 | Thanked: 5,249 times | Joined on Jan 2009 @ Barcelona
#9
Originally Posted by AapoRantalainen View Post
But this is not acceptable that I (as an user) needed to do that.
I fully agree. I mean, I would say adopting btrfs would be a risky move _today_. And Jolla adopted it years ago AND probably knew they would be stuck with their current kernel version. I'd never used btrfs in this situation!

Perhaps they're still planning to use for something more useful than factory restore (e.g. snapshots?). But I keep thinking that the factory restore usecase would best be served with recovery images...

Originally Posted by juiceme View Post
Actually BTRFS was a good choise and made sense when it was decided to be used. (and still does) BTRFS has good feature set that is used and needed on the device and is optimized to minimize FLASH wear.
Not sure about whether it minimizes flash wear by any measure... The feature set is nice, but is barely used by Sailfish (not a bad thing since that makes SFOS mostly FS independent). To my knowledge only factory restore uses _any_ btrfs feature!

Originally Posted by juiceme View Post
The real problem is users cramming too much data on the device, so the more sensible choise would have been having the device with 64GB storage in the first place...
Yeah well, I'm in the group who thinks that if the filesystem fails to handle ENOSPC (no free space error) properly, it's broken beyond repair. On Ext4, reserving around 5% of blocks/inodes ensures this problem almost never happens. On Btrfs, how many blocks you need to reserve? 83%?

Originally Posted by coderus View Post
imho btrfs is just because of qualcomm architecture
Doubt it, since all the other qcom partitions are ext4...
 

The Following 8 Users Say Thank You to javispedro For This Useful Post: