Linux Your experience with BTRFS?

vishalrao

vishalrao

Global Moral Police
Skilled
Hi,

Revisiting btrfs after many moons and long story short, now that Ubuntu 22.04 LTS has kernel 6.2 available and having tried it with openSUSE Tumbleweed too on my various computers, it seems to be ready for prime time?

I've reformatted my main computer and reinstalled KDE neon and elementary OS (with Win11 canary just in case it's needed for things like firmware updates) and these are based off Ubuntu 22.04 with kernel 6.2 so I've opted for btrfs with default mount options and noatime, compress=zstd as additional options.

I have NVMe SSDs on all my machines and a sata 2.5 inch SSD on my main PC and wondering if these options are optimal for performance and SSD specific operations like async trim and reduced write amplification? Hopefully the old trope "btrfs ate my data" is no longer true.

Wanted to get your thoughts/experiences with btrfs of late, especially compared to the venerable EXT4. It was nice to see a few old threads here with all the btrfs enthusiasm from so many years ago.

Thanks!

PS: See https://btrfs.readthedocs.io/
 
Long time ago. Like a decade. Used it mainly because we wanted a cow fs and zfs wasn’t stable on linux.

But as of today, i feel that a good file system is the one about which the end user won’t have to give a ****! It should be like an endless basket where i just throw stuff. Don’t wanna know how that system organizes itself or anything like that.
 
BTRFS is the default on many distros nowadays. It should be reliable enough. But I don't have any long term experience with it. I still prefer ext4 due to higher performance overall.
 
I've been using btrfs as my primary FS on my primary OS for over 10 years, when it was "experimental", and there used to be no manual fsck for it. I never lost any data, in spite of power issues, kernel panics due to my other experiments all of which give no time for a clean umount before power off.

Initially I used to take backups on ext3 for any btrfs data, but I judged them to be almost equally reliable for my purposes around 5 years ago. The features I like about btrfs are snapshots, including automatic snapshots on software installations using snapper, compress options, btrfs send/receive, and occasionally COW is a life saver.

The only problem with your options can that maybe swapfile is not supported with compress= zstd, otherwise you should be good. I personally prefer relatime over noatime even though it is slower.
 
Thanks @kiran6680 for your input. Interesting to see you have been using btrfs for so long since its early days! I only temporarily tried it out, was never brave enough to daily drive it.

Send/receive is used for backups?

Swap I earlier used to keep a separate swap partition common for my multiple OS installations, then later on I simply avoided any swap, but after reading that linux loves to swap I read about simply doing apt install zram-tools and edit /etc/default/zramswap configuration and you are quickly up and running with swap in memory to save some writes to SSD.

I think I prefer btrfs over other modern filesystems because it has checksums instead of journaling which again saves some writing to SSD.

I've also read that noatime can detrimental for some workloads like databases? So relatime is good.

Compression helps alleviate SSD write amplification apparently which is the only reason I enabled it, not for any space savings really.

My main computer is now wiped clean with fresh penta-boot installs of Win11 canary (just in case needed for things like firmware updates) and KDE neon, elementary, neon plasma 6 experimental and opensuse tumbleweed gnome, (all btrfs now) so these cover my preferred desktop environments too.

Going forward I'd like to daily drive KDE neon now that I've also figured out running Win11 with KVM qemu.

Windows is boring now and annoying too with all the adware, nagware, bloatware.
 
vishalrao said:
Send/receive is used for backups?

Swap I earlier used to keep a separate swap partition common for my multiple OS installations, then later on I simply avoided any swap, but after reading that linux loves to swap I read about simply doing apt install zram-tools and edit /etc/default/zramswap configuration and you are quickly up and running with swap in memory to save some writes to SSD.
Click to expand...
Just read the documentation about btrfs send/receive it seems to be inspired by what we used to call a zfs send stream format. We had a problem with migrating to/from zfs cloud to our storage arrays the zfs stored their data in zfs send stream format but when asked the data format details they said it’s proprietary. We were all working at oracle /facepalm/ so we had to create a solaris vm on our kvm based appliance to solve the problem.

Coming to backups and snapshots; btrfs is a cow fs. This means whenever you overwrite a block it simply creates a new block and modifies the references. This means old data is never overwritten. So creating a snapshot or backup is as simple as modifying metadata of the sub volume. So they are extremely fast. Just like zfs.

Now coming to swap volumes. I don’t think we need them anymore in current configurations. Back in the day swap was used to move data from ram to hdd to create an illusion of lot of memory. Nowadays just buy more ram. This also brings up the logic behind creating swap on ramdisk… why???
 
Apparently linux loves to swap even if you have plenty of RAM, and having swapfile itself in RAM saves regular writes to SSD, hence zram-utils package which enables zramswap.

There's OpenZFS out there these days, right? I don't recall (and not bothered to check) whether it's a journaling and/or CoW FS.

It was a sad day in history (for me at least) when SUN (and its various cool tech) was acquired by Oracle, but that is digression.
 
vishalrao said:
Apparently linux loves to swap even if you have plenty of RAM, and having swapfile itself in RAM saves regular writes to SSD, hence zram-utils package which enables zramswap.
Click to expand...
I don’t recollect installing linux with swap in my past 10 or so years… I strongly believe that “linux loves swap” is tribal knowledge.

Openzfs seems to be cow.
 
vishalrao said:
What makes you believe "linux loves to swap" is "tribal" (or old wives' tale) knowledge... When I was reading up on this topic, came across posts like this -> https://haydenjames.io/linux-performance-almost-always-add-swap-space/ which lead me to believe enabling swap is a good thing.
Click to expand...
swap is not mandatory, don't create one + have enough ram and it should be fine. I had done that few years back. Maybe it helps in some case ( linked article), but if you don't like it you have option.
I changed OS and it seems by default i got one created ( 2gb swap, 16gb ram ). So now i have removed it, if there is an issue will update here.
 
vishalrao said:
linux loves to swap
Click to expand...
Yeah, theoretically it is kind of true, that the vm subsystem is the same for file backed memory, and non-file based memory parts. The complete lack of swap pushes execution into less efficient branches. Practically it doesn't matter much, especially as the dynamics can adjusted with swappiness.
TinTinSnowy said:
Bitrot is a very rare event. I take regular backups with checksum validation.
Click to expand...
Rare, but catastrophic if you care about your data. I've run into reproducible, but of course silent bitrot due to faulty memory. And backups with checksum validation are enough to combat bitrot, roughly equivalent to btrfs / zfs solutions for practical purposes.
 
vishalrao said:
What makes you believe "linux loves to swap" is "tribal" (or old wives' tale) knowledge... When I was reading up on this topic, came across posts like this -> https://haydenjames.io/linux-performance-almost-always-add-swap-space/ which lead me to believe enabling swap is a good thing.
Click to expand...
Read that article, seems to me that he made is test to validate his confirmation bias.

Lets see, when you compare RAM and swap; disk access is (say roughly) 500 times slower. so a cache miss and swap-in would be 500 times lower and even swapping out an unused page would create an io which is very very slow.

in older days when you had 640kb RAM then having a swap which is roughly twice the size of RAM would give you an illusion of 3times the memory. but but a very slow memory. and when you wanted huge chunks of data then computer will give you the same error message as when it didn't have the swap. but in today's age, we have boat loads of ram and ram is relatively cheap. so just add more RAM which is way way faster than swap disk.

Now, coming to ramdisk based swap; swap in and swap outs will only add one more memory transfer where you move pages from here to there in the memory. how is that supposed to improve performance? I mean swapping is creating unnecessary movement of pages in ram. Actually if you move pages across numa nodes, it will be much more costlier operation than just copying memory in the same numa node. I mean like let the page live where it is instead of moving it in the name of swapping and add more dma calls...

Personally anecdote time... I have done extensive io tests on enterprise servers for a very long time like saturating network links etc in SAN environments. never used swap on my servers/virtual machines. I dont think swap is a good thing in today's world where you could easily slap a 32G extra ram. if an application using more memory then probably it is a badly written application.




Anyone looked into xfs? its a fairly advanced filesystem too...
 
XFS is available generally, right? (like ext4 i mean, no issues like ZFS) IIRC xfs is standard for RHEL (or it was) and it's a journaling FS. Now don't call it tribal :p but I've got the impression that journaling is bad (many writes) for SSDs but of course I could be wrong, haven't really looked much into this FS... btrfs FTW !
 
vishalrao said:
XFS is available generally, right? (like ext4 i mean, no issues like ZFS) IIRC xfs is standard for RHEL (or it was) and it's a journaling FS. Now don't call it tribal :p but I've got the impression that journaling is bad (many writes) for SSDs but of course I could be wrong, haven't really looked much into this FS... btrfs FTW !
Click to expand...
Xfs is the old IBM filesystem, got ported to Linux ages ago. Now that IBM has bought redhat, they made xfs the default for redhat Linux and even one of the the Fedora installers makes xfs the default.

Journalling is necessary to recover after a crash : ext3, ext4, jfs, xfs, NTFS, btrfs, zfs all have some way of journaling.
 
Back
Top