Skip to contentSkip to conversation

gazillions of Incorrect local/global backref count

DISCUSSION Christoph Anton Mitterer 4 participants 6 messages Sep 4, 2016 – Sep 5, 2016 Btrfs file system

lore
Share & tools
lore
#0 lore raw

Hey.

I just did a btrfs check on my notebooks root fs, with:

$ uname -a
Linux heisenberg 4.7.0-1-amd64 #1 SMP Debian 4.7.2-1 (2016-08-28)
x86_64 GNU/Linux
$ btrfs --version
btrfs-progs v4.7.1

during:
checking extents

it found gazillions of these:
Incorrect local backref count on 1107980288 root 257 owner 17807428 offset 13568135168 found 2 wanted 3 back 0x2d69990 Incorrect local backref count on 1107980288 root 257 owner 14055042 offset 13568135168 found 2 wanted 3 back 0x2d69930 Incorrect global backref count on 1107980288 found 4 wanted 6 backpointer mismatch on [1107980288 61440]
Incorrect local backref count on 1108049920 root 257 owner 17807428 offset 13568262144 found 2 wanted 5 back 0x2d69ac0 Incorrect local backref count on 1108049920 root 257 owner 14055042 offset 13568262144 found 2 wanted 5 back 0x2d69b20 Incorrect global backref count on 1108049920 found 4 wanted 10 backpointer mismatch on [1108049920 77824]

See stdout/err[0] logfiles from the check.

What do they mean?

And does this now mean that data is corrupted and I should try to recover that from a backup?
And if so... how to I map the affected addresses above back to files?

Or can I somehow simply (and foremost cleanly/perfectly) correct these errors?

Thanks in advance,
Chris.

[0] http://christoph.anton.mitterer.name/tmp/public/dbf3aee0-725a-11e6-8fd0-0019dbacbbbf/

#1 lore raw
Quoted 38 lines

-----Original Message-----
From: [email protected] [mailto:linux-btrfs- [email protected]] On Behalf Of Christoph Anton Mitterer
Sent: Sunday, 4 September 2016 2:51 PM
To: [email protected]
Subject: gazillions of Incorrect local/global backref count

Hey.

I just did a btrfs check on my notebooks root fs, with:

$ uname -a
Linux heisenberg 4.7.0-1-amd64 #1 SMP Debian 4.7.2-1 (2016-08-28)
x86_64 GNU/Linux
$ btrfs --version
btrfs-progs v4.7.1

during:
checking extents

it found gazillions of these:
Incorrect local backref count on 1107980288 root 257 owner 17807428 offset 13568135168 found 2 wanted 3 back 0x2d69990 Incorrect local backref count on 1107980288 root 257 owner 14055042 offset 13568135168 found 2 wanted 3 back 0x2d69930 Incorrect global backref count on 1107980288 found 4 wanted 6 backpointer mismatch on [1107980288 61440]
Incorrect local backref count on 1108049920 root 257 owner 17807428 offset 13568262144 found 2 wanted 5 back 0x2d69ac0 Incorrect local backref count on 1108049920 root 257 owner 14055042 offset 13568262144 found 2 wanted 5 back 0x2d69b20 Incorrect global backref count on 1108049920 found 4 wanted 10 backpointer mismatch on [1108049920 77824]

See stdout/err[0] logfiles from the check.

Quoted 8 lines

What do they mean?

And does this now mean that data is corrupted and I should try to recover that from a backup?
And if so... how to I map the affected addresses above back to files?

Or can I somehow simply (and foremost cleanly/perfectly) correct these errors?

The errors are wrong. I nearly ruined my filesystem a few days ago by trying to repair similar errors, thankfully all seems ok. Check again with btrfs-progs 4.6.1 and see if the errors go away, mine did.
See open bug https://bugzilla.kernel.org/show_bug.cgi?id=155791 for more details.

Cheers,
Paul.

���{.n�+�������+%�����ݶ��w��{.n�+����{���k~���^n�r���z���h����&���z��z�ޗ�+��+zf���h���~����i��������z_��j:+v���)ߣ�m

#2 lore raw
Quoted 6 lines · Paul Jones

The errors are wrong. I nearly ruined my filesystem a few days ago by trying to repair similar errors, thankfully all seems ok. Check again with btrfs-progs 4.6.1 and see if the errors go away, mine did.
See open bug https://bugzilla.kernel.org/show_bug.cgi?id=155791 for more details.

Thanks for the pointer :)
I can at least confirm that my system seems to work normal, scrub didn't bring any errors either, nor are there any kernel messages...

The interesting thing... I have some pretty large btrfs on those 8TiB seagate disks (nearly full with some million files)... which I have also scanned with v4.7... and no errors.
Only my system fs seems to be "affected".

Well it's not my first case of false positives in btrfs check (https://
www.mail-archive.com/[email protected]/msg48325.html)... so I was more relaxed this time (at least a bit ;-) ).

Cheers,
Chris.

#3 lore raw
In reply to Christoph Anton Mitterer
Quoted 28 lines · Christoph Anton Mitterer

Hey.

I just did a btrfs check on my notebooks root fs, with:

$ uname -a
Linux heisenberg 4.7.0-1-amd64 #1 SMP Debian 4.7.2-1 (2016-08-28)
x86_64 GNU/Linux
$ btrfs --version
btrfs-progs v4.7.1

during:
checking extents

it found gazillions of these:
Incorrect local backref count on 1107980288 root 257 owner 17807428 offset 13568135168 found 2 wanted 3 back 0x2d69990 Incorrect local backref count on 1107980288 root 257 owner 14055042 offset 13568135168 found 2 wanted 3 back 0x2d69930 Incorrect global backref count on 1107980288 found 4 wanted 6 backpointer mismatch on [1107980288 61440]
Incorrect local backref count on 1108049920 root 257 owner 17807428 offset 13568262144 found 2 wanted 5 back 0x2d69ac0 Incorrect local backref count on 1108049920 root 257 owner 14055042 offset 13568262144 found 2 wanted 5 back 0x2d69b20 Incorrect global backref count on 1108049920 found 4 wanted 10 backpointer mismatch on [1108049920 77824]

Quoted 4 lines

See stdout/err[0] logfiles from the check.

What do they mean?

https://bugzilla.kernel.org/show_bug.cgi?id=155791
http://www.spinics.net/lists/linux-btrfs/msg58142.html

Signature · 1 line
Chris Murphy
#4 lore raw
In reply to Christoph Anton Mitterer
Quoted 8 lines · Christoph Anton Mitterer

Hey.

I just did a btrfs check on my notebooks root fs, with:

$ uname -a
Linux heisenberg 4.7.0-1-amd64 #1 SMP Debian 4.7.2-1 (2016-08-28)
x86_64 GNU/Linux
$ btrfs --version
btrfs-progs v4.7.1

As others replied, it's a false positive. There's a fix on the way, once it's done I'll release 4.7.2.

#5 lore raw
Quoted 3 lines · David Sterba

As others replied, it's a false positive. There's a fix on the way, once
it's done I'll release 4.7.2.

Yeah... thanks again for confirming... and sorry that I've missed the obvious earlier post :-/

Best wishes,
Chris.