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

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.

(now late for work!)
devel mailing list --
To unsubscribe send an email to
Fedora Code of Conduct:
List Guidelines:
List Archives:

Reply via email to