Jon Steinhart wrote in &lt;202108292212.17TMCGow1448973(a)darkstar.fourwinds.com&gt;om>: |I recently upgraded my machines to fc34. I just did a stock |uncomplicated installation using the defaults and it failed miserably. | |Fc34 uses btrfs as the default filesystem so I thought that I'd give it ... |Any of the rest of you have any experiences with btrfs? I'm sure that it |works fine at large companies that can afford a team of disk babysitters. |What benefits does btrfs provide that other filesystem formats such as |ext4 and ZFS don't? Is it just a continuation of the "we have to do |everything ourselves and under no circumstances use anything that came |from the BSD world" mentality? From a small man perspective i can say i use btrfs. I have seen more problems with filesystems in these 29 months than in the ~36 years (well, 22 if you only count Unix, mostly FreeBSD) before. I have learned that i have to chattr +C my vm/ directory in order to avoid filesystem errors which can only be solved by deleting the corrupted files (which were not easy to find out, inspect-internal inode-resolve could have helped a bit better, but .. why?). I have seen (factual) snapshot receive errors that were not indicated by the tool's exit status. With dangling files laying around. I have seen +C attributes missing on the target filesystem from played in snapshots. I have found it impossible to mount external devices because "BTRFS warning (device <unknown>): duplicate device /dev/sdc2 devid 1 generation 3977" even though the former umount was successful (i must admit i had used lazytime mount option there, be sure not to do that for BTRFS). I know where you coming from, i tried it all without success. With all the little tools that do not do what you want. I found it quite ridiculous that i had to shrink-resize my filesystem in an iteration because the "minimum possible" size was adjusted each and every time, until i finally was where the actual filesystem usage indicated you would end up with from the beginning. (defrag did not prevent this.) On the other hand i am still here, now on Luks2, now with xxhash checksums and data and meta DUP (instead of RAID 1, i thought). Same data, just moved over onto. I think i would try out ZFS if it would be in-kernel. The FreeBSD Handbook is possibly the best manual you can have for that. But i mean the ZFS code is much, much larger than BTRFS, BTRFS serves me really, really good for what i want and need, and i am sailing Linux stable/latest (4.19, now 5.10) here, on a free and small Linux distribution without engineering power aka supervision, that sails somewhat the edge of what all the many involved projects produce, with problems all over the place, sometimes more, sometimes less, some all the time. That is nothing new, you have to live with some deficiencies in the free software world; i just find it sometimes hard to believe that this is still true for Linux with the many many billions of Dollars that went in, and the tens of thousands of people working on it. I really hate that all the Linux kernel guys seem to look forward only, mostly, you have to go and try out the newest thing, maybe there all is good. Of course .. i can understand this (a bit). That is the good thing of using such an engineering-power distribution, you likely get backports and have a large user base with feedback. |In my limited experience btrfs is a BiTteR FileSystem to swallow. Well often people say you need to know what you are doing. That is hard without proper documentation, and the www is a toilet. And noone writes HOWTOs any more. But, for example, if i do not use an undocumented kernel parameter (rtw88_pci.disable_aspm=1), and use wifi and bluetooth (audio) in conjunction, then i have to boot into the Windows startup screen in order to properly reinitialize my wifi/bluetooth chip. Or else you are dead. And that even though it seems the Linux driver comes from the Chip creator itself. So i think a "chattr +C" here and there, it can be directory-wide, it could be a mount or creation option, isn't that bad. Also it is just me having had a go (or julia or nim; or perl) on using _one_ filesystem with several subvolumes for anything; if i would have used my (well, security context only) old-style way of doing things and used several hard partitions with individual filesystems, i would have used +C from the beginning for that one. Especially if i would have read it in the manual page. I do believe todays' journalled, checksummed, snapshot'able copy-on-write filesystems are complex beasts. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

Linus replied: I'm not sure how much people use the fancier features, but lots of people seem to use btrfs in production these days, and the maintenance team seems responsive and stable. Of the local disk filesystems we have, I'd pick any of ext4, btrfs and xfs as stable and well-maintained. Picking any of those is fine, and the choice would come down to which distro you use, and _possibly_ whether you want any of the particular features. But on the whole, most people don't seem to care deeply about the more intricate features unless they have very specific use-cases.