Always welcome, I didn’t do any research what this means exactly, let’s hope it is not just marketing :)
The switch to Btrfs will use a single-partition disk layout, and Btrfs’ built-in volume management. The previous default layout placed constraints on disk usage that can be a difficult adjustment for novice users. Btrfs solves this problem by avoiding it.
Neat. The default layout before (in Fedora) made / way too big, wasting a lot of space that could have been used in ${HOME}… especially on (smallish) SSDs.
optimizations for SSDs,
Always welcome, I didn’t do any research what this means exactly, let’s hope it is not just marketing :)
Btrfs supports compression, as the article says. Enabling compression is expected to improve the SSD’s life span because you have fewer data to write. (the less you write, the less the disk wears out.) Of course, it may depend highly on your workload.
For SSDs, are they completely random access? Or is there some benefit to storing related blocks close together ala on a spinning disk for sequential read?
I’m using VMs in GNOME Boxes and they are stored in ${HOME}/.local/share/gnome-boxes so the exact opposite :-D In either case it should be solved with btrfs…
Perhaps btrfs has come a long way, but I just can’t bring myself to trust it since my experience with it around 5 years ago lead to having to reinstall my operating system (and losing a day of work). Perhaps that’s me being irrational, but I’ll stick to filesystems that have never given me trouble.
One interesting thing about this is it’s completely different to what redhat are doing. Unless I’ve missed a memo.
(I work for Redhat, but not on storage.)
Isn’t RedHat working fairly hard on building Stratis ?
Just found this: https://access.redhat.com/discussions/3138231 about btrfs/stratis.
Great! Looking forward to it!
Always welcome, I didn’t do any research what this means exactly, let’s hope it is not just marketing :)
Neat. The default layout before (in Fedora) made
/way too big, wasting a lot of space that could have been used in${HOME}… especially on (smallish) SSDs.Btrfs supports compression, as the article says. Enabling compression is expected to improve the SSD’s life span because you have fewer data to write. (the less you write, the less the disk wears out.) Of course, it may depend highly on your workload.
For SSDs, are they completely random access? Or is there some benefit to storing related blocks close together ala on a spinning disk for sequential read?
There’s some setup cost to select the block in which the sector resides, so accessing adjacent sectors is still faster than truly random accesses.
If you look at SSD benchmarks, they do in fact give better throughput in sequential reads vs. random.
I must be an outlier in finding their / very small. I use docker and had to move where it puts its images because Fedora made my / too tiny.
I’m using VMs in GNOME Boxes and they are stored in
${HOME}/.local/share/gnome-boxesso the exact opposite :-D In either case it should be solved with btrfs…Perhaps btrfs has come a long way, but I just can’t bring myself to trust it since my experience with it around 5 years ago lead to having to reinstall my operating system (and losing a day of work). Perhaps that’s me being irrational, but I’ll stick to filesystems that have never given me trouble.
This line confused me, does this mean that upgrading will also switch from Ext4 to Btrfs?
Great, I might even try to switch from XFS after 25 years. Kidding, I obviously won’t, there is no reason, not a single one.