Linux

Chill. That thing just hit the mainline.

Don't use it quite yet

Uff, somehow missed your post. See mine. That's the FS I'm hoping to use next. I'm waiting for it to support swapfile, or alternatively read from official sources they won't ever support it, :). But yes, that's the one I'm looking forward to use.

I'm curious, why do you use LVM with BTRFS and not just use BTRFS built in subvolumes?

"It's never lost data for me. Yet" is what they mean.

I totally agree, the only file system I've lost data with as a result of a file system corruption not caused by hardware errors or power problems in 35 years has been btrfs. FAT even served me better.

SSDs* HDDs*

f2fs does one of the weirdest things with compression by default: the files are compressed but they still take up the same amount of blocks as the uncompressed files. This can get you the slight performance boost of compressed files, but doesn’t actually save you space which is an odd choice. You can enable a flag in the kernel but it has other effects as well.

If you're on spinning rust with a modern CPU, compression actually helps your read/write speeds quite a bit. It's faster for the CPU to compress/decompress then read/write less data because hard drives are so slow in comparison.

Seeing that user Flatpaks are installed in the home folder, I see this as an interesting strategy. EXT4 still beats BTRFS in certain read/write benchmarks. My only problem being that you lose provisioning.

I don't see a lot of people talking about this here, but BTRFS subvolume provisioning is probably the best reason to use BTRFS - and BCacheFS - not just CoW or snapshotting.

The old way, of having a set beginning and end of a partition, is like caveman technology to me now. Subvolumes are here to stay and I am happy about that.

If I need to do a little distrohop now, even though I wouldn't (rpm-ostree rebase go brrrr), all I'd do is delete an recreate the "@" subvolume (or the root subvolume) without touching another partition or subvolume. All storage space is shared between subvolumes, basically, removing that boundary distinction between them, so I get to keep the files, permissions and meta data in my "@home" and my "@var" subvolumes, even though I get rid of the old "@" to replace it with a new one.

Therefore the idea of having storage that is reliant upon partitioning, ordering sectors one after another, having to defragment and keep strict separations between them is absolutely archaic to me. I'll gladly take a slight performance hit just for the convenience of avoiding all that.