Pyra's root filesystem.


133794m3r

Member
Joined
Sep 17, 2010
Messages
42
Since the pyra's going to be using debian, and since you're going with 3.17 I see no reason to not use btrfs+zlib compression to help reduce the number of writes on the sd card, along with speeding up the overall reading of the data off of it. Admittedly it doesn't yet have lz4(which I hate) but you do have zlib compression available to compress the various binaries/files on the rootfs to help decrease boottime.
 
The Pyra is still a bit off from actually being produced, It may get several new kernel versions by the time an official OS release is done.
 
I don't see what kernel version we eventually (initially) ship with has on the rootfs format. ISTR that btrfs has been proposed before, but initially dismissed as being too immature still, although by the time the Pyra ships that might have changed.

Either way, I don't see why we shouldn't discuss this at this juncture.

However, reading up on btrfs I can't see why it would be especially well suited for the Pyra's flash storage. And in terms of compressing for boot speed, wouldn't LZO be a more obvious candidate as it's much easier to decompress?
 
Hypothetically, wouldn't the Pyra support btrfs, so that the user could choose ext4 or btrfs or whatever they wanted?
 
It's not even stable...

I'd prefer something that we know won't cause major FS corruption. In my recent memory (within the last two years) a friend of mine had massive FS corruption in BtrFS. I wouldn't go near it for another 5 years, but that's just me. On my main machines, I only last year went over from ext3 to ext4, so I guess that speaks for my conservative ways...
 
I've been running btrfs in raid mode on my home desktop /home for about two years now. No corruptions whatsoever. Wasn't there just recently a presentation where google deemed it ready for real production use?
 
It's not even stable...

I'd prefer something that we know won't cause major FS corruption. In my recent memory (within the last two years) a friend of mine had massive FS corruption in BtrFS. I wouldn't go near it for another 5 years, but that's just me. On my main machines, I only last year went over from ext3 to ext4, so I guess that speaks for my conservative ways...
To be honnest I had mixed feeling about BtrFS. I definitely would prefer ZFS for important storatge. I use Freenas at home as a NAS.

ZFS need some ressouce and lvoes RAM. So while it is great on a storage server or server in general, it is not well suited for a mobile device.

I know ZFS can be used with 1GB of RAM, but it is no optimum. Maybe once all mobile device have 4 or 8GB of ram ;)

This being said I have multiple computers (family...) with OpenSuse 13.1. I am simply using the default option (BtrFS partition layout with auto snapshots). Did not run into any usse.

Jolla decided to use BtrFS on their phone, which quite surprised me. Again I use a Jolla phone and no complain. They use snapshot for backup / restore.
 
Last edited by a moderator:
The one hesitation I have with brtfs is that I have heard stories of it going to pot if you get too close to filling up the volume. Has it been determined for sure how much internal storage will be available? I forgot. Using btrfs might be a bad idea unless the internal storage is going to have a lot of extra space after a typical desktop install of debian and a bunch of software.

Chris on Linux Action Show got burned pretty bad with this and he said he would never use it again on a drive unless he knew he would never fill it beyond 80% (at least I am pretty sure my memory is close on this detail).

As long as we can choose, then I am certainly fine with including it as an option for others to use, but I don't want to use it.
 
The one hesitation I have with brtfs is that I have heard stories of it going to pot if you get too close to filling up the volume. Has it been determined for sure how much internal storage will be available? I forgot. Using btrfs might be a bad idea unless the internal storage is going to have a lot of extra space after a typical desktop install of debian and a bunch of software.

Chris on Linux Action Show got burned pretty bad with this and he said he would never use it again on a drive unless he knew he would never fill it beyond 80% (at least I am pretty sure my memory is close on this detail).

As long as we can choose, then I am certainly fine with including it as an option for others to use, but I don't want to use it.
Oh come on, when you use something before it's stable then it's your own fault.
(I'm not saying anything about the current stability of btrfs, I don't know)
 
Even if we all agree that btrfs is technically stable, I don't feel comfortable putting a copy-on-write filesystem on anything used by non-techy consumers. These types of file systems really aren't meant for average people beause they require fairly technical procedures to repair them when things go wrong.

Does anyone here really want to deal with the following on a device that will almost certainly have a base file system that is pretty close to full and sees a fair amount of random writes?:

http://marc.merlins.org/perso/btrfs/post_2014-05-04_Fixing-Btrfs-Filesystem-Full-Problems.html

Who wants to write the tutorial to include in the box with every Pyra that will be plain enough language to explain to the average gamer (not linux user) how to rebalance a full internal file system using a USB drive? Not me. :/

Again, it should certainly be an option for those who want it (and presumably, therefore, know what they are getting into), but making this the default sounds like a disaster waiting to happen for people who buy this to play games and aren't advanced users to begin with.

If I am wrong, I am open to correction, as long as there are real-world proofs that give technical explanations and not merely philosophical/religious reasons (as has been going on a lot in the larger systemd discussions).
 
I would like the option. I would have no problem following those instructions if it goes wrong.
 
I've played around a bit with btrfs and I agree that it is cool, but I also agree it wouldn't add much as a default file system. Because most of the cool features are either irrelevant to the regular user (like resizing on the fly) or too cumbersome (e.g. deduplication, probably even the snapshot feature) and balancing is quite slow even with a fast disk so that it probably is not much fun on an SD card based system.
 
Last edited by a moderator:
Here's a thought...

Use the Pyra development board and -test- the different available host FS formats for speed.

I noticed on the Pandora that some SD cards were MUCH faster under EXT2 than EXT3 or EXT4 in actual use - but not so much under dd benchmarks.
 
Back
Top