Pyra's root filesystem.

[Grench]

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.

I did the dd benchmarks that we had back when SD cards weren't faster than the slots they were going in.  Everyone was trying to find the fastest SD cards so several of us were benching them.

Although the dd benchmarks would show similar performance results for EXT4 as EXT2, actual in-application performance on EXT4 was MUCH slower for me than EXT2 was.  That may have been card dependent - hard to tell.

Regardless, I think that it should be possible to do some basic testing of different FS formats to find out what performs best on the particular NAND that gets used in the Pyra - whatever that winds up being.

 

[myNewUsername]

HI, I am glad BTRFS  is being discussed. I have used it as one and only fs for ~5mnths on my laptop and ~1mnth on my siduction powered chromebox (16G). both are up to date with debian unstable packages.

I love the snapshot feature, without it I would  not experiment as much as I like. About the concern that this will be too complicated to use, a minimal front end that lets users set up snapshotting as cron-jobs and roll back would go a long way.

The Jolla phone (http://jolla.com/) uses BTRFS and lets users roll back. According to this report of problems with a full btrfs (https://together.jolla.com/question/30822/root-and-home-disks-full-and-causing-various-problems/), a minimum of 1,5G should be unallaocated.... that is not much to loose at all, but i can very well see that we dont want these kind of problems, or require users to solve them manually. So if the OS can alert the user or in some way reduce the probility of filling the disk, btrfs should be doable and worth it IMO, if only for snapshotting and roll-back.

3 days ago i noticed my chromebook had 99% disk usage after testing out games without cleaning up. I did not notice any problems beside my inability to download stuff. maybe these problems are solved???

Okay thanks for hearing me out, needed to vent my positive experiences about btrfs.

 

[λ the β-Redex Reducer]

This is a bit of a bump but still relevant. Will BtrFS be useable on the Pyra? I'm afraid of bitrot and supposedly BtrFS is more resistant against it. Maybe not by default but if it's an option I might go for BtrFS depending on how good it protects against bitrot. Suposedly Ext4 has nothing to protect against bitrot and that's not good. I am not smelling any foul odour coming from my disk yet so I guess that my bits are not rotting right now but I'm afraid that in the future they'll start rotting.

I've read that ZFS is good against bitrot as well but supposedly it's a bit of a hassle to use it with Linux since it's license prevents it from being merged with Linux.

 

[daveshah]

Hopefully, the Pyra will either ship with kernel 5.6 or at least have a 5.6 update soon after release, so btrfs should definitely be usable - even 5.7 is pretty close to working on the Pyra if you really want to be at the cutting edge.

 

[levi]

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...

Good luck! It's currently well over five years since you wrote that! I'm still rocking ext4 on all of my SD cards, but I may try out btrfs when I reformat this card to use partition encryption.

 

[λ the β-Redex Reducer]

You can also encrypt using LUKS. That's what I do. But maybe I'll switch to whatever BtrFS has for encryption since I'm going to use BtrFS anyway for the bitrot detection.

 

[levi]

Yes, I encrypt on my build machine using LUKS on my home partition. I did that more or less as an experiment, and it seems robust enough containing an ext4 partition. But my laptop which I sometimes take away with me could probably do with more protection in case I lose it, and that isn't encrypted yet.

I wasn't aware BtrFS had it's own encryption scheme. I'll have to look at that. But my main protection against bitrot at present is backups, which we should all be maintaining regardless.

 

[λ the β-Redex Reducer]

Back-ups-only do not work against bitrot because it does not detect it. You'll just be backing up the damaged bits until the only good copies get removed for being too old. In order for back-ups to be effective against bitrot you need bitrot detection so that you know when to restore from back-up and when to create a back-up. I already have back-up which is why I only really need a better bit corruption detection.

As for encryption; supposedly it's planned. But I hardly know anything about Btrfs right now. I'm just looking for a good filesystem with good bitrot detection for the Pyra and it seems Btrfs might be what I need. My laptop uses LUKS which works fine as far as I know. Why do you need extra protection? Is LUKS unsafe?

 

[levi]

No, dmcrypt/LUKS ontop of a btrfs seems to be a supported way of working at present as far as I've been reading. The story on native encryption seems a bit confused at present, with a post on a mailing list from 2016 I think saying work was being done to enable it but reading the archwiki today says it's not being worked on (I haven't digged in to see if that's old content yet though), and a post on the btrfs wiki that says it's a third option, but that dmcrypt/LUKS is well supported. So that's the way I'll go when I come to rebuild this system.

Yeah, automatic but unmonitored backups don't help, but my system only backs up changed files, so if there are files in folders I don't expect, I can start to suspect bitrot.

 

[λ the β-Redex Reducer]

My system also only backs up changed files, but I do not want to take the time to check all those files. My FS should do that for me!