IIRC btrfs may cause early wear of the memory, but I'm no expert and I've never really used btrfs.

On the other hand, btrfs has worse performances under stress compared to ext4, which may really impact the experience of the game as it may (depending on the game) lengthen massively load times.

I'm also pretty curious for those games using streaming assets in how such a difference would work.

On the other hand, it is a pretty good improvement for saving space nonetheless. Even on full rigs. I'm using around 30 gigs for prefixes alone (some are legacy I should get rid of), so I'd say it's still a good improvement.

btrfs has come a long way. Its the default for OpenSuse's desktop (still?) and to be honest, I can't tell a difference between it and Ext4 in terms of performance. That said, I don't really stress my harddrive, I just play games.

Now, some of its features though.... I really like them over ext4. The snapshot/rollback is very nice and has saved me a few times when I was still getting used OpenSuse and made some dumb changes while goofing around. That can be really nice. The way it mounts the snapshots and handles volumes is still a little confusing to me. I could see Valve making use of that to keep a copy of SteamOS off to the side for a "return to factory defaults" type setting, or rolling back to a stable system if there's a bad update (powerloss mid update, etc)

BTRFS has been on my system since I built it and switched to OpenSuse in 2018 and at least in my experience, I can't really find a reason to complain about it. No data loss, performance issues, etc. etc.

Quoting: Loftyhttps://www.winehq.org/pipermail/wine-devel/2021-July/191267.html

Could be a big deal for the Steam Deck if it is using a filesystem like Btrfs.
Should save many GB's especially useful on the lower tier 64gB model.

Thoughts?

My thoughts are that it wouldn't need to be a big deal if the m.2 storage would be removable.

Quoting: denyasisbtrfs has come a long way. Its the default for OpenSuse's desktop (still?) and to be honest, I can't tell a difference between it and Ext4 in terms of performance. That said, I don't really stress my harddrive, I just play games.

Now, some of its features though.... I really like them over ext4. The snapshot/rollback is very nice and has saved me a few times when I was still getting used OpenSuse and made some dumb changes while goofing around. That can be really nice. The way it mounts the snapshots and handles volumes is still a little confusing to me. I could see Valve making use of that to keep a copy of SteamOS off to the side for a "return to factory defaults" type setting, or rolling back to a stable system if there's a bad update (powerloss mid update, etc)

BTRFS has been on my system since I built it and switched to OpenSuse in 2018 and at least in my experience, I can't really find a reason to complain about it. No data loss, performance issues, etc. etc.

Quoting: MisterPaytwickIIRC btrfs may cause early wear of the memory, but I'm no expert and I've never really used btrfs.

While openSUSE uses btrfs as the default for normal HDDs, it doesn't recommend using it for SSDs but uses XFS there as default. I guess they do it for a reason but haven't looked into the subject in detail. Because of that I think there might be issues (wear or whatever) using btrfs on flash-type memory.

BTW: The Synology NAS also use btrfs as their default filesystem, for normal disks. Don't have an SSD or something (they support M.2, NVMe, SSD) in there so I can't tell what they use for that.

Last edited by peta77 on 31 Jul 2021 at 7:57 pm UTC

Quoting: peta77While openSUSE uses btrfs as the default for normal HDDs, it doesn't recommend using it for SSDs but uses XFS there as default.

You sure? I'm pretty sure BTFS is default. I see no mention of the drive type mattering:
https://en.opensuse.org/SDB:BTRFS

https://doc.opensuse.org/documentation/leap/reference/html/book-reference/cha-expert-partitioner.html

It's defaulted to BTRFS on my SSD desktop and HDD laptop. Am I missing something?

Quoting: denyasis

Quoting: peta77While openSUSE uses btrfs as the default for normal HDDs, it doesn't recommend using it for SSDs but uses XFS there as default.

You sure? I'm pretty sure BTFS is default. I see no mention of the drive type mattering:
https://en.opensuse.org/SDB:BTRFS

https://doc.opensuse.org/documentation/leap/reference/html/book-reference/cha-expert-partitioner.html

It's defaulted to BTRFS on my SSD desktop and HDD laptop. Am I missing something?

Well at least that was the case when I installed the system and somewhat later added an additional SSD. But OK, that's a while ago. So maybe the recommendations/defaults changed in the meantime. It's not like I'm doing this often.

It's all good, my last install was in 2019, so I was worried I had wrong info when I did my installs.

In my opinion the while reason to do BTRFS on / is for the snapshot feature. I feel it's a must have, especially for a consumer hand held like the Steam Deck, with Valve likely managing the snapshots to some degree (like a factory reset snapshot).

Hopefully, soon, maybe with some help from Valve we'll reach parity with Windows XP's system rollback! (Kinda joking).

Note that the performances benchmark I saw was back in 2016 or 2017 and very benchmark-y (so less real world issues, iirc, but more raw limits, the bcachefs website / overstreet's blog should still have them). I'm looking forward still for bcachefs, but at the same time, as I dig OpenSUSE, I'm starting to look into btrfs and I don't know it well enough yet, so take what I pointed at earlier with a pinch of salt. Yet another reason to check this out.

It's more about the idea that writing more would wear out more the SSD, but I could be wrong about it nonetheless (anybody with the knowledge, feel free to give me some flak about that)

The point about the snapshots to do factory reset is actually a solid one tho, as far as I picture how you can do those.

Last edited by MisterPaytwick on 2 Aug 2021 at 5:22 pm UTC

The technical descriptions of "early" SSDs always mentioned a limit on guaranteed number of correct writes, but in the meantime they only show MTBF in number of hours (at least on shop pages). And at work we had a couple of SSDs die because they were used for "/tmp", swap or compiling lots of code and doing QA (we generate lots of output) on a daily basis. This happened with Linux and Windows workstations though. But the failure rate was a lot higher than for HDDs.
So this might be a serious issue if modern flash chips still have such limitations. A few years ago a couple of sites talked about new types of flash memory (NAND flash or something like that?). If those don't have such problems (I'm not familiar with the details, so I don't know), that could make the problem obsolete. But I guess we need some kind of hardware guru to answer that question.

Quoting: peta77So this might be a serious issue if modern flash chips still have such limitations.

As far as I know, flash memory, NAND or not, have that inherent problem. It's just the tech.

Hence I mount my system on a NAND, but mount /var, /tmp and /home on my HDD.