On Mon, Jun 29, 2020 at 5:17 PM Dominique Martinet
<asmadeus(a)codewreck.org> wrote:
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.)
- 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. And it's my mistake to
even mention it. Fedora folks won't be asked or recommended to use
that.
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.
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.
--
Chris Murphy