On Tue, Jun 25, 2019 at 12:58 AM Nikolay Borisov <nbori...@suse.com> wrote:
>
>
>
> On 25.06.19 г. 5:49 ч., Chris Murphy wrote:
> > False alarm, not a new issue at all!
> >
> > I have a different system on kernel 5.1.11 using Btrfs as root with
> > persistent systemd-journald storage, and compress=zstd. And I never
> > have problems with it, so I never run btrfs check on it, until now.
> > And yep, same problem. All the journals that have been rotated, are
> > zstd compressed, are nocow, and btrfs check complains about them the
> > same way.
> >
> > root 257 inode 62526 errors 1040, bad file extent, some csum missing
> > root 257 inode 62734 errors 1040, bad file extent, some csum missing
> >
> > Turns out this is just btrfs check noise. There's definitely no
> > corruption. These files still pass journalctl --verify which is
> > checking its own internal checksumming in the journal file.
> >
> > I don't know what's best practice. I think on any kind of flash media,
> > I'd rather not have +C by default, so that the logs compress on the
> > fly, and also rather not have defragment on rotate because that also
> > just increases wear by rewriting everything. Yes the journals are
> > heavily fragmented if they are allowed to COW, but I don't think I
> > really care about legacy files being a little slower on flash. *shrug*
>
> But why are your nocompress files being compressed? I just tested latest
> misc-next branch and a mounted fs with -ocomopress=zstd correctly skips
> compression on a file where chattr +C has been set?

test.journal has +C set and filefrag shows it's not encoded, single extent.

$ sudo btrfs fi def -vf test.journal

Result? No compression still.

$ sudo btrfs fi def -vf -czstd test.journal

Result? It's compressed.

What is systemd doing? I can't really read the code, but in the
comments they say they are unsetting +C and then defragmenting?

https://github.com/systemd/systemd/blob/master/src/journal/journal-file.c

line 371:
/* Be friendly to btrfs: turn COW back on again now,
* and defragment the file. We won't write to the file
* ever again, hence remove all fragmentation, and
* reenable all the good bits COW usually provides
* (such as data checksumming). */

Except all of the logs in /var/log/journal/<machineid>/ have +C set.
So I don't understand that comment at all. They might think they're
unsetting it, but it has no effect because the new file inherits the
+C set on the enclosing directory the journal files are in:
/var/log/journal/<machineid>

There's more btrfs defragment stuff later in this same journal-file.c
code but I don't understand how it relates to "turn COW back on
again", just that they are definitely submitting files for
defragmentation at log rotate time. But possibly they way they submit
it is different than 'btrfs fi defrag' default, and somehow it gets
compressed.

Anyway this isn't new, all three of my cleanly installed systems on
Btrfs behave this way (all have compress=zstd set). Years ago I
mentioned this same behavior on this list with respect to zlib. The
difference back then I think is that btrfs check never complained.

-- 
Chris Murphy

Reply via email to