Thanks for the reply. It feels a bit dismissive after the time I spent there, so I'll assume I wasn't clear and my point didn't get across (I did send that mail at 1AM and haven't slept much lately...): I'm not complaining about any particular bug here, just that the overall use & feel is way too rough. I think what we (fedora) need right now are more people using it, the thread is full of ""anecdotal evidences"" one way or another, mine isn't anything more or less than that, but first encourage people to use it more and polish tools/documentation then actually make it default. (If this can happen in time for f33 that would be great, but my opinion at this point isn't optimistic) To give one more example I've remembered now, `btrfs scrub` will only report the first file that is corrupted for a given extent. btrfs being cow, it is possible (and was my case yesterday) that some of the extents belong to multiple files and there is no easy way to report all the files involved : the btrfs scrub status command should have an option to do that, really. kernel messages can be throttled so if some line is missing you'll miss a corrupted extent, and parsing dmesg to use `btrfs ins logical-resolve` is far from obvious to a new user. I also feel the mix of "this command runs in foreground" (e.g. defrag, some variants of balance? not clear to me) and "this command starts a background thread" (e.g. scrub unless -B given) is a bit messy and confusing. Yes we don't want users to actually run these manually, so we need things that need to run to automagically start in background and some nice gnome popup or whatever to notify of any problem instead; but that isn't here yet either. Chris Murphy wrote on Mon, Jun 29, 2020: > > Recap of the problems I ran into: > > - bug in btrfs-convert where it just aborts in the middle with an > ... > > - second bug in btrfs-convert, running scrub immediately after > ... > > My view is that btrfs-convert is something of a proof of concept. Yes > it should fail gracefully if it's going to fail, and the rollback > should work short of having made certain modifications (listed in the > documentation) post-install. And maybe there'd be interest in the > Fedora community at some point down the road doing a test day or test > week, to gather a lot of good data on converting ext4 to btrfs. I > don't know but my suspicion is that as any file system ages, it's > becoming increasingly non-deterministic in its layout, and that might > affect the conversion success rate. New file systems seem to convert > without problems, and sometimes older ones don't (and by older I mean > 1-2 years.) Yes, btrfs-convert isn't a battle-hardened tool; I'm not judging btrfs based on just this. Honestly, out of the 4 hours I spent last night; btrfs-convert wasn't even included there. I had failed first then prepared on another copy and things worked rather well overall -- it could get better error messages, a big warning in man page perhaps, but overall I've saved more time with btrfs-convert than I would have spent trying to juggle resizing partition multiple times to copy data over. Once again: not complaining about the result, my point isn't about the bugs I reported but about documentation. > > - I have (had) a working kexec-kdump setup and usually set the sysctl > > kernel.panic_on_warn to 1... That also wasn't great because since > > someone suggested using flushoncommit here I went for it (sounds better > > than chattr +C to me?), but machine crashing after 30s wasn't fun, > > They're noisy WARNON messages, but not crashes. bugs eat data. seriously. I have panic_on_warn on all my systems, so a warn IS a crash for me. Because of the switch kexec wasn't reconfigured yet (needs more than 30s to rebuild initrd) and this was really annoying, I had to take a video of the screen to read it that's just about as bad as things can get... With my kernel developer hat, I'll also say warnings should also never be ignored: even if you're smart enough to decide this one is begnin, you'll miss other bug messages if you let this one happen all the time. > And it's my mistake to even mention it. Fedora folks won't be asked or > recommended to use that. It's not just you. I've seen it recommended by Zygo on IRC as well just the other day. It's not broadly advertised but it is a good feature that really makes sense for some workloads, people will try to use it. What's frustrating is that it's been around since 4.15 and nobody seemed to care: either it's really harmless in the way btrfs use it and it should be quietened down (Zygo said he patches his kernels to remove the message), or it's not and it should be fixed. For reference I currently am using: - autodefrag, because I read it helps with small dbs e.g. firefox sqlite databases and things like that and wanted to see the impact it has in the background - compress=zstd (not sure about your :1, I don't think the cpu usage difference will be that big; it's mostly increasing write latency as you said so shouldn't change much) - discard=async as recommended here and "will-soon-be-default" - ssd (already default based on rotational sysfs) - space_cache=v2 (soon-to-be-default) Once again these stuff are hard for users to decide themselves so we should think about fedora defaults, but I think they're mostly well documented at least. > > I think that's about it, points about VMs / DB needing either chattr +C > > That's what will happen, and it'll be set for the user. Users aren't > expected to know these things. It still needs to be readily-available informations for "semi-advanced" users: these files won't get checksum at least. > > Compression in particular is a very noticeable gain for my local storage > > (mostly sources and git trees) so I had been wanting to try, this thread > > gave me the push... > > > > (from a quick compsize on fs root: > > Type Perc Disk Usage Uncompressed Referenced > > TOTAL 66% 121G 183G 192G > > none 100% 87G 87G 88G > > zlib 46% 1.8K 4.0K 4.0K > > zstd 35% 33G 95G 104G > > I need to check what's uncompressible but probably git objects > > themselves, and a few VM images it looks like ; still more than decent) > > chattr +c by default uses zlib. It's possible to specify zstd using > 'btrfs property' - but again this too will be done for the user on > clean installs. And it will be limited to select locations. Possibly > down the road there can be desktop integration so folks can choose > specific home directories. > > I use -o compress=zstd:1 mount option instead to compress everywhere, > but some sporadic benchmarks on one older machine suggests a small > write time performance decrease, with no change in read performance. > man 5 btrfs has more info. mount option seems simpler for me for clean installs - btrfs is smart enough to not compress if it detects the first few blocs aren't compressible, and force compress definitely isn't something users should need to care about. Thanks, -- Dominique (now late for work!) _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
