Btrfs Receives A Very Important Last Minute Fix For Linux 6.3

[phoronix]

Phoronix: Btrfs Receives A Very Important Last Minute Fix For Linux 6.3

Ahead of the Linux 6.3 kernel being potentially released as stable on Sunday, two last minute patches for the Btrfs file-system driver were submitted today to address a pressing problem since Linux 6.2...

https://www.phoronix.com/news/Btrfs-Discard-Tuning-Linux-6.3

[dreamcat4]

i still do not trust this fs. but in particular it is supposed to slow down if too many snapshots or clone trees accumulate (or whatever they are called in the btfs terminology). so i wonder if this stated fix actually improves the performance in that situation. or if its just more deeply inherent to the way btrfs is implemented

getting past that, i still find the command line interface pretty daunting and not so user friendly. so you know... hope they fix / improve performance but am still actively resisting it. even if they fix those performance impacted situations. still did not win my trust. for example what if i mess up the commands because they are too complex / not intuitive

[ALRBP]

for example what if i mess up the commands because they are too complex / not intuitive

You can do a lot of harm with a simple rm, mv or cp and messed-up arguments.
That said, MDADM\LVM\XFS is the choice of trust ; not Btrfs.

[lectrode]

i still do not trust this fs [...]even if they fix those performance impacted situations. still did not win my trust. for example what if i mess up the commands because they are too complex / not intuitive

There is an old saying "Trust but verify". In the case of storage, you can generally trust that your files are there, but you should verify (i.e. have an external backup). That is true for any filesystem, not just those that had a rough start. If you have everything important backed up elsewhere, it shouldn't matter if your drive dies or if you screw something up.

That said, it helps to have a "throwaway" / test system (like an old laptop or a VM) if you want to try out any potentially breaking / complex tasks without having to worry about spending a great deal of time rebuilding your main system should things not go as planned. Anyone developing for production knows the benefit of testing in dev/pilot beforehand - it's not because what they're using is inherently prone to breakage or unusable, but because hardware wear and tear and human error are things that exist and can manifest at any point in the process of changing things.

Personally, I've been using btrfs for nearly a decade on all of my systems and my users' systems. The only storage issues I've run into have been hardware related. If a drive goes out or starts to go out, I don't bother trying to clone what I can scrape off the drive - I have automated backups in place such that as long as the device has an internet connection, they immediately backup important files as soon as they are created or modified. Filesystem-level snapshots are used in the event of user error (i.e. mistakenly changing or deleting files). And I always assume the user will need twice as much storage as what they think they need. Storage is cheap enough that if usage is over 70%, it's time to either cleanup or migrate to larger storage or both.

[zexelon]

i still do not trust this fs. but in particular it is supposed to slow down if too many snapshots or clone trees accumulate (or whatever they are called in the btfs terminology). so i wonder if this stated fix actually improves the performance in that situation. or if its just more deeply inherent to the way btrfs is implemented

getting past that, i still find the command line interface pretty daunting and not so user friendly. so you know... hope they fix / improve performance but am still actively resisting it. even if they fix those performance impacted situations. still did not win my trust. for example what if i mess up the commands because they are too complex / not intuitive

Yeah... I have played with it a bit myself and not interested at all... its going to take quite a few more years before its reputation is recovered also. It seems to be permanently locked in the "experimental" feel.

That said, this patch is really about performance. These "types" of patches come out occasionally for all the different Linux file systems.

[scottishduck]

You can do a lot of harm with a simple rm, mv or cp and messed-up arguments.
That said, MDADM\LVM\XFS is the choice of trust ; not Btrfs.

Which would be why redhat ditched btrfs and made Stratis

[skeevy420]

You can do a lot of harm with a simple rm, mv or cp and messed-up arguments.
That said, MDADM\LVM\XFS is the choice of trust ; not Btrfs.

Yeah. I ran 'rm -rdf' my makepkg source folder a few days ago when my pinky went stupid and hit Enter instead of / in-between typing and tab completion.

[F.Ultra]

You can do a lot of harm with a simple rm, mv or cp and messed-up arguments.
That said, MDADM\LVM\XFS is the choice of trust ; not Btrfs.

XFS does not checksum the data so no that is not the choice I would make for trust over btrfs.

[zexelon]

XFS does not checksum the data so no that is not the choice I would make for trust over btrfs.

If you dig into the way btrfs does checksums, its not actually the "blessed holy water sprinkling all healing data resurrection" feature that tons of people think it is. In fact in a large number of cases it wont save your data at all... 90% of storage devices actually do checksums in hardware these days (or some form of CRC...etc.) ...

I would argue that the vast majority of "failure modes" that would take down a file system like XFS, EXT or the like will also trash btrfs just as fast and easily.

These failure modes are largely in two simplified categories:

1. Hardware failure... pretty much no fs is going to save you here, though a properly setup volume manager style can warn you and give you time to salvage in some cases.
2. Users... no software survives interaction with the user... ever!

The vast majority of data loss issues happen because of #2... Snapshots can help you here sure... but a committed well intentioned user will pave your way to data loss hell in gold faster than anything else on the planet. They will also likely be so effective at it that no locally hosted file system will be able to recover your data easily.

In fact the tool set for btrfs can make user induced data loss even easier if its not well wrapped in a scripted management system.

All of that said, its been said many times by many people here when discussing file systems... always have your backups somewhere else!

The number one thing that has saved me and my users: "restic + Backblaze B2"

[V1tol]

I migrated to btrfs on both my system drive and files drive last summer. Both are Samsung NVME SSDs - 970 PRO and 980 PRO. First thing I did - disabled quotas support as I don't need them and they are known to have a performance hit even when not used. And configured snappy snapshots using wonderful GUI tool called Btrfs Assistant. Didn't have any problems though I did not have with XFS or EXT4 either. Couple of times snapshots helped me to recover some deleted files - for example I found out that C&C 3: Tiberium Wars don't support Steam cloud saves and I removed Proton prefix folder with them.

As for the issue described in this article - I have constantly blinking HDD activity led, it blinks like 5 times per second almost all the time. Disabling discard on mount points and rebooting confirmed this was the issue. Earlier I tried to find out what that was but iotop didn't show any disk activity though it was blinking. SMART stats didn't show any suspicious reads and writes increase so I just gave up and didn't think it may be connected to filesystem at all.