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.
Pyra's root filesystem.
- Thread starter 133794m3r
- Start date
- Joined
- Jan 18, 2010
- Messages
- 11,411
Last edited by a moderator:
levi
Still fresh, damnit!
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?
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?
Right now, we're working with kernel 3.18 already.
ible
professional vim user
Hypothetically, wouldn't the Pyra support btrfs, so that the user could choose ext4 or btrfs or whatever they wanted?
kaprikawn
Very Active Member
slaeshjag
¯\_(ツ)_/¯
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'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...
bzar
A Commando
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?
Pickle
Mega GP Mania
opensuse has also now moved to btrfs for the root filesystem as default
the_marshal
Very Active Member
- Joined
- Aug 27, 2010
- Messages
- 212
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:
groovechicken
Member
- Joined
- Mar 7, 2014
- Messages
- 78
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.
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.
Granitehead
Advanced Member
- Joined
- Oct 16, 2009
- Messages
- 3,011
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)
kaprikawn
Very Active Member
For the ones that want to know more about BTRfs, here is an old presentation from 2012:
https://www.youtube.com/embed/hxWuaozpe2I?feature=oembed
Personally... I still would use a more conservative FS like ext3 or zfs, but that's my admin mentality.
https://www.youtube.com/embed/hxWuaozpe2I?feature=oembed
Personally... I still would use a more conservative FS like ext3 or zfs, but that's my admin mentality.
groovechicken
Member
- Joined
- Mar 7, 2014
- Messages
- 78
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).
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).
Silent-Hunter
Hardcore Member
- Joined
- May 29, 2010
- Messages
- 3,485
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:
Grench
Forum Addict!
- Joined
- Oct 3, 2008
- Messages
- 6,629
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.
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.
bzar
A Commando
Disclaimer: You may know this already. In that case disregard and carry on.
Did you benchmark using these? You can also test read speeds using hdparm.
Did you benchmark using these? You can also test read speeds using hdparm.
Similar threads
