Re: 4.11.6 / more corruption / root 15455 has a root item with a more recent gen (33682) compared to the found root node (0)

[Ivan Sizov]

2017-08-01 0:39 GMT+03:00 Ivan Sizov <sivan...@gmail.com>:
> 2017-08-01 0:17 GMT+03:00 Marc MERLIN <m...@merlins.org>:
>> On Tue, Aug 01, 2017 at 12:07:14AM +0300, Ivan Sizov wrote:
>>> 2017-07-09 10:57 GMT+03:00 Martin Steigerwald <mar...@lichtvoll.de>:
>>> > Hello Marc.
>>> >
>>> > Marc MERLIN - 08.07.17, 21:34:
>>> >> Sigh,
>>> >>
>>> >> This is now the 3rd filesystem I have (on 3 different machines) that is
>>> >> getting corruption of some kind (on 4.11.6).
>>> >
>>> > Anyone else getting corruptions with 4.11?
>>> Yes, a lot. There are at least 3 cases, probably I've missed something.
>>> https://www.spinics.net/lists/linux-btrfs/msg67177.html
>>> https://www.spinics.net/lists/linux-btrfs/msg67681.html
>>> https://unix.stackexchange.com/questions/369133/dealing-with-btrfs-ref-backpointer-mismatches-backref-missing/369275
>>
>> Indeed. My main server is happy back on 4.9.36 and while my laptop is
>> stuck on 4.11 due to other kernel issues that prevent me from going back
>> to 4.9, it only corrupted a single filesystem so far, and no other ones
>> that I've noticed yet.
>> Hopefully that will hold :-/
>>
>> Marc
>> --
>> "A mouse is a device used to point at the xterm you want to type in" - A.S.R.
>> Microsoft is to operating systems 
>>    what McDonalds is to gourmet 
>> cooking
>> Home page: http://marc.merlins.org/ | PGP 
>> 1024R/763BE901
>
> I want to try mounting and checking FS under Live images with
> different kernels tomorrow. Today's Fedora Rawhide image seems to be
> built incorrectly. Can you advice me where to get a fresh live image
> with 4.12 kernel (it's not important which distro that will be)?
>
> --
> Ivan Sizov
Mounting problem persists:
on 4.13.0 with btrfs-progs v4.11.1 (latest Fedora Rawhide Live)
on 4.10.0 with btrfs-progs v4.9.1 (Ubuntu 17.04 Live)
on 4.9.0 with btrfs-progs v 4.7.3 (Debian 9 Stretch Live)
"btrfs check --readonly" also gives the same output on 4.11, 4.10 and 4.9.

Marc, how did you roll back and fix those errors?

-- 
Ivan Sizov
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 4.11.6 / more corruption / root 15455 has a root item with a more recent gen (33682) compared to the found root node (0)

[Ivan Sizov]

2017-08-01 0:17 GMT+03:00 Marc MERLIN <m...@merlins.org>:
> On Tue, Aug 01, 2017 at 12:07:14AM +0300, Ivan Sizov wrote:
>> 2017-07-09 10:57 GMT+03:00 Martin Steigerwald <mar...@lichtvoll.de>:
>> > Hello Marc.
>> >
>> > Marc MERLIN - 08.07.17, 21:34:
>> >> Sigh,
>> >>
>> >> This is now the 3rd filesystem I have (on 3 different machines) that is
>> >> getting corruption of some kind (on 4.11.6).
>> >
>> > Anyone else getting corruptions with 4.11?
>> Yes, a lot. There are at least 3 cases, probably I've missed something.
>> https://www.spinics.net/lists/linux-btrfs/msg67177.html
>> https://www.spinics.net/lists/linux-btrfs/msg67681.html
>> https://unix.stackexchange.com/questions/369133/dealing-with-btrfs-ref-backpointer-mismatches-backref-missing/369275
>
> Indeed. My main server is happy back on 4.9.36 and while my laptop is
> stuck on 4.11 due to other kernel issues that prevent me from going back
> to 4.9, it only corrupted a single filesystem so far, and no other ones
> that I've noticed yet.
> Hopefully that will hold :-/
>
> Marc
> --
> "A mouse is a device used to point at the xterm you want to type in" - A.S.R.
> Microsoft is to operating systems 
>    what McDonalds is to gourmet 
> cooking
> Home page: http://marc.merlins.org/ | PGP 
> 1024R/763BE901

I want to try mounting and checking FS under Live images with
different kernels tomorrow. Today's Fedora Rawhide image seems to be
built incorrectly. Can you advice me where to get a fresh live image
with 4.12 kernel (it's not important which distro that will be)?

-- 
Ivan Sizov
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 4.11.6 / more corruption / root 15455 has a root item with a more recent gen (33682) compared to the found root node (0)

[Ivan Sizov]

2017-07-09 10:57 GMT+03:00 Martin Steigerwald <mar...@lichtvoll.de>:
> Hello Marc.
>
> Marc MERLIN - 08.07.17, 21:34:
>> Sigh,
>>
>> This is now the 3rd filesystem I have (on 3 different machines) that is
>> getting corruption of some kind (on 4.11.6).
>
> Anyone else getting corruptions with 4.11?
Yes, a lot. There are at least 3 cases, probably I've missed something.
https://www.spinics.net/lists/linux-btrfs/msg67177.html
https://www.spinics.net/lists/linux-btrfs/msg67681.html
https://unix.stackexchange.com/questions/369133/dealing-with-btrfs-ref-backpointer-mismatches-backref-missing/369275

If an additional debug info is needed, I'm ready to provide it.

-- 
Ivan Sizov
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: "Unable to find ref byte nr ...." (4.11 somehow fishy?)

[Ivan Sizov]

o_bit drm_kms_helper serio_raw sdhci_pci
> drm e1000e sdhci mmc_core ptp pps_core video
> [  625.657371] CPU: 0 PID: 2919 Comm: btrfs-cleaner Tainted: G
> W  OE   4.11.8-200.fc25.x86_64 #1
> [  625.657372] Hardware name: Hewlett-Packard HP EliteBook 2540p/7008,
> BIOS 68CSU Ver. F.60 11/11/2015
> [  625.657372] Call Trace:
> [  625.657374]  dump_stack+0x63/0x86
> [  625.657376]  __warn+0xcb/0xf0
> [  625.657377]  warn_slowpath_fmt+0x5a/0x80
> [  625.657390]  __btrfs_free_extent.isra.61+0x821/0xe40 [btrfs]
> [  625.657401]  ? btrfs_search_slot+0x429/0x9d0 [btrfs]
> [  625.657416]  ? btrfs_merge_delayed_refs+0x61/0x6c0 [btrfs]
> [  625.657428]  __btrfs_run_delayed_refs+0x501/0x12b0 [btrfs]
> [  625.657443]  ? btrfs_get_token_64+0x105/0x120 [btrfs]
> [  625.657456]  btrfs_run_delayed_refs+0x8f/0x2a0 [btrfs]
> [  625.657473]  ? free_extent_buffer+0x4b/0xa0 [btrfs]
> [  625.657486]  btrfs_should_end_transaction+0x48/0x60 [btrfs]
> [  625.657498]  btrfs_drop_snapshot+0x3e0/0x920 [btrfs]
> [  625.657512]  btrfs_clean_one_deleted_snapshot+0xbc/0x100 [btrfs]
> [  625.657527]  cleaner_kthread+0x133/0x180 [btrfs]
> [  625.657529]  kthread+0x109/0x140
> [  625.657542]  ? __btree_submit_bio_start+0x20/0x20 [btrfs]
> [  625.657543]  ? kthread_park+0x90/0x90
> [  625.657545]  ret_from_fork+0x2c/0x40
> [  625.657546] ---[ end trace 1c4d5dd9396052af ]---
> [  625.657548] BTRFS: error (device dm-1) in __btrfs_free_extent:6942:
> errno=-2 No such entry
> [  625.657550] BTRFS info (device dm-1): forced readonly
> [  625.657553] BTRFS: error (device dm-1) in
> btrfs_run_delayed_refs:2961: errno=-2 No such entry
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

I have exactly the same errors, also on 4.11 kernel, but RAID-1 with 4 disks.
And I can't fix it till two months. Yes, I'm quite a bit lazy and
didn't have much spare time))

Unfortunately, my last post in mailing list left unanswered:
https://www.spinics.net/lists/linux-btrfs/msg67681.html

Seems like it's a common problem.
This answer on StackOverflow contains an output (in "btrfs check")
which is identical to one in my system:
https://unix.stackexchange.com/questions/369133/dealing-with-btrfs-ref-backpointer-mismatches-backref-missing/369275

Tomorrow I'll try to run "btrfs check" with 4.12 kernel and progs.
Maybe someone have a "success story"?


-- 
Ivan Sizov
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What are the typical usecase of "btrfs check --init-extent-tree"?

[Ivan Sizov]

Small clarification after reading journal: errors stats weren't
changed on sda since December, but READ error count was increased on
sdc (especially in May, when I first noticed problems) and sdb.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What are the typical usecase of "btrfs check --init-extent-tree"?

[Ivan Sizov]

I've just noticed a huge number of errors on one of the RAID's disks.
"btrfs dev stats" gives:

[/dev/sdc1].write_io_errs0
[/dev/sdc1].read_io_errs 305
[/dev/sdc1].flush_io_errs0
[/dev/sdc1].corruption_errs  429
[/dev/sdc1].generation_errs  0

[/dev/sda1].write_io_errs58331
[/dev/sda1].read_io_errs 57438
[/dev/sda1].flush_io_errs37
[/dev/sda1].corruption_errs  10110
[/dev/sda1].generation_errs  0

[/dev/sdb1].write_io_errs0
[/dev/sdb1].read_io_errs 91
[/dev/sdb1].flush_io_errs0
[/dev/sdb1].corruption_errs  0
[/dev/sdb1].generation_errs  0

[/dev/sdd].write_io_errs0
[/dev/sdd].read_io_errs 0
[/dev/sdd].flush_io_errs0
[/dev/sdd].corruption_errs  0
[/dev/sdd].generation_errs  0


On the one hand, it explains the cause of problems, don't it? On
another, I hardly understand how to fix such a complex problem: it
seems that my stupid "check --repair" attempts corrupted FS internals
heavily.
Can I just remove sda from RAID-1 and run rebalance?

2017-07-27 17:02 GMT+03:00 Ivan Sizov <sivan...@gmail.com>:
> My RAID-1 FS have multiple "backpointer mismatch" errors. "btrfs check
> --repair" doesn't help but only increases the number of errors.
> Initially, only 2 roots were affected (uncleanly deleted snapshots I
> suppose). But after I ran "check --repair" new "check --readonly"
> returns such errors on almost every root!
> You can read a small prehistory in this mailing list thread:
> https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg64640.html
> Recently I decided to resume my attempts to recover the FS and, at
> some point I booted into my system (Fedora 25 with 4.11.3-200 kernel
> with patch from the thread mentioned above). A Snapper daemon tried to
> remove some corrupted snapshot and, as result, triggered btrfs-cleaner
> bug. Now I can neither RW-mount the FS nor run scrub (scrub is
> "aborted" in 00:00:00 after start).
>
> How does "--init-extent-tree" deal with backref problems? Will those
> backrefs completely reconstructed?
>
> Can similar "backref not found" and "backpointer mismatched" errors
> have very different causes and different fix scenarios?
>
> --
> Ivan Sizov



-- 
Ivan Sizov
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

What are the typical usecase of "btrfs check --init-extent-tree"?

[Ivan Sizov]

My RAID-1 FS have multiple "backpointer mismatch" errors. "btrfs check
--repair" doesn't help but only increases the number of errors.
Initially, only 2 roots were affected (uncleanly deleted snapshots I
suppose). But after I ran "check --repair" new "check --readonly"
returns such errors on almost every root!
You can read a small prehistory in this mailing list thread:
https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg64640.html
Recently I decided to resume my attempts to recover the FS and, at
some point I booted into my system (Fedora 25 with 4.11.3-200 kernel
with patch from the thread mentioned above). A Snapper daemon tried to
remove some corrupted snapshot and, as result, triggered btrfs-cleaner
bug. Now I can neither RW-mount the FS nor run scrub (scrub is
"aborted" in 00:00:00 after start).

How does "--init-extent-tree" deal with backref problems? Will those
backrefs completely reconstructed?

Can similar "backref not found" and "backpointer mismatched" errors
have very different causes and different fix scenarios?

-- 
Ivan Sizov
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Help on using linux-btrfs mailing list please

[Ivan Sizov]

2017-06-19 13:15 GMT+03:00 Jesse <btrfs_mail_l...@mymail.isbest.biz>:
> Thanks again. So am I to understand that you go into your 'sent'
> folder, find a mail to the mail list (that is not CC to yourself),
> then you reply to this and add the mail list when you need to update
> your own post that no-one has yet replied to?
Yes, exactly.

-- 
Ivan Sizov
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Help on using linux-btrfs mailing list please

[Ivan Sizov]

2017-06-19 13:03 GMT+03:00 Jesse <btrfs_mail_l...@mymail.isbest.biz>:
> Thanks Ivan.
> What about when initiating a post, do I do the same eg:
> TO: myself
> CC: mailing list
>
> or do I
> TO: mailing list
> CC: myself
If your mail client doesn't have "sent" folder, you can, of course,
follow one of these examples. But I didn't face with such situation
ever.

-- 
Ivan Sizov
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Help on using linux-btrfs mailing list please

[Ivan Sizov]

2017-06-19 13:03 GMT+03:00 Jesse <btrfs_mail_l...@mymail.isbest.biz>:
> Thanks Ivan.
> What about when initiating a post, do I do the same eg:
> TO: myself
> CC: mailing list
>
> or do I
> TO: mailing list
> CC: myself
When initiating a post you should to specify "TO: mailing list" only,
without any other addresses. At least I used to initiate posts in such
way.



-- 
Ivan Sizov
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Help on using linux-btrfs mailing list please

[Ivan Sizov]

2017-06-19 12:32 GMT+03:00 Jesse <btrfs_mail_l...@mymail.isbest.biz>:
> So I guess that means when I initiate a post, I also need to send it
> to myself as well as the mail list.
You need to do it in the reply only, not in the initial post.

> Does it make any difference where I put respective addresses, eg: TO: CC: BCC:
You need to put a person to whom you reply in "TO" field and mailing
list in "CC" field.

-- 
Ivan Sizov
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Help on using linux-btrfs mailing list please

[Ivan Sizov]

You should reply both to linux-btrfs@vger.kernel.org and the person
whom you talk to.

2017-06-19 11:37 GMT+03:00 Jesse <btrfs_mail_l...@mymail.isbest.biz>:
> I have subscribed successfully and am able to post successfully and
> eventually view the post on spinics.net when it becomes available:
> eg: http://www.spinics.net/lists/linux-btrfs/msg66605.html
>
> However I do not know how to reply to messages, especially my own to
> add more information, such as a call trace.
> 1. I do not receive an email of my post for which I could reply
> 2. The emails that I do receive from the list are from the respective
> sender, and not the vger.kernel.org, as such I do not even know how to
> reply to someone in a way that it ends up on the mailing list and not
> directly to that person.
>
> Could someone please be so kind as to direct me to a good guide for
> using this mailing list?
>
> Thanks
>
> Jesse
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Ivan Sizov
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/6] add sanity check for extent inline ref type

[Ivan Sizov]

2017-06-02 1:57 GMT+03:00 Liu Bo <bo.li@oracle.com>:
> On Thu, Jun 01, 2017 at 11:26:26PM +0300, Ivan Sizov wrote:
>> 2017-06-01 20:35 GMT+03:00 Liu Bo <bo.li@oracle.com>:
>> > After I went through the output of leaf's content, most parts of the
>> > leaf is sane except the two corrupted items, it's still not clear to
>> > me what caused the corruption, there could be some corner cases that
>> > I'm not aware of.
>> >
>> > If fsck doesn't work for you, then a recovery from backup may be the
>> > best option.
>>
>> I don't need to run any repair procedures because system is working
>> normally. Most likely that corrupted extents belong to files located
>> somewhere in /home.
>> Do you mean I should run fsck in order to determine which files are
>> corrupted? What are proper options to run fsck with?
>
> I see.  Scrub has found that there are some corrupted metadata, if you
> want to fix that corrupted thing, fsck may be helpful.  Due to my
> test, 'btrfs check /your_disk' fixed my corruption.
>
> With this patch set, at least you won't get a crash when accessing the
> corrupted extent inline ref.
>
> -liubo

After applying patchset I unwisely ran rsync and then FS became RW-unmountable.
"btrfs-check -p --readonly" gave me many errors of different types.
After "btrfs check -p --repair" I'd mounted the FS and ran scrub.
But not all errors was fixed and boot attempt caused RO-remounting again.

Now check gives this:

[liveuser@localhost-live ~]$ sudo btrfs check -p --readonly /dev/sda1
Checking filesystem on /dev/sda1
UUID: 4b30bf4a-2331-40fb-a108-e1a34aa14221
ref mismatch on [2398147911680 4096] extent item 12, found 13
Backref 2398147911680 root 27665 owner 17074270 offset 4096 num_refs 0
not found in extent tree
Incorrect local backref count on 2398147911680 root 27665 owner
17074270 offset 4096 found 1 wanted 0 back 0x562ce582c260
backpointer mismatch on [2398147911680 4096]
ref mismatch on [2398176096256 4096] extent item 12, found 13
Backref 2398176096256 root 27665 owner 17074270 offset 8192 num_refs 0
not found in extent tree
Incorrect local backref count on 2398176096256 root 27665 owner
17074270 offset 8192 found 1 wanted 0 back 0x562cd886b7f0
backpointer mismatch on [2398176096256 4096]
ref mismatch on [2398285246464 4096] extent item 12, found 13
Backref 2398285246464 root 27665 owner 17074270 offset 16384 num_refs
0 not found in extent tree
Incorrect local backref count on 2398285246464 root 27665 owner
17074270 offset 16384 found 1 wanted 0 back 0x562cd7e16900
backpointer mismatch on [2398285246464 4096]
ref mismatch on [2404820451328 16384] extent item 0, found 1
Backref 2404820451328 parent 27641 root 27641 not found in extent tree
backpointer mismatch on [2404820451328 16384]
owner ref check failed [2404820451328 16384]
ref mismatch on [2405008687104 16384] extent item 0, found 1
Backref 2405008687104 parent 27641 root 27641 not found in extent tree
backpointer mismatch on [2405008687104 16384]
owner ref check failed [2405008687104 16384]
ref mismatch on [2405015797760 16384] extent item 0, found 1
Backref 2405015797760 parent 27641 root 27641 not found in extent tree
backpointer mismatch on [2405015797760 16384]
owner ref check failed [2405015797760 16384]
ref mismatch on [2405036081152 16384] extent item 0, found 1
Backref 2405036081152 parent 27641 root 27641 not found in extent tree
backpointer mismatch on [2405036081152 16384]
owner ref check failed [2405036081152 16384]
ref mismatch on [2405057970176 16384] extent item 0, found 1
Backref 2405057970176 parent 27641 root 27641 not found in extent tree
backpointer mismatch on [2405057970176 16384]
owner ref check failed [2405057970176 16384]
ref mismatch on [2405176311808 16384] extent item 0, found 1
Backref 2405176311808 parent 27641 root 27641 not found in extent tree
backpointer mismatch on [2405176311808 16384]
owner ref check failed [2405176311808 16384]
ref mismatch on [2477885390848 16384] extent item 0, found 1
Backref 2477885390848 parent 27641 root 27641 not found in extent tree
backpointer mismatch on [2477885390848 16384]
owner ref check failed [2477885390848 16384]
ref mismatch on [2478010597376 16384] extent item 0, found 1
Backref 2478010597376 parent 27641 root 27641 not found in extent tree
backpointer mismatch on [2478010597376 16384]
ref mismatch on [2478014939136 16384] extent item 0, found 1
Backref 2478014939136 parent 27641 root 27641 not found in extent tree
backpointer mismatch on [2478014939136 16384]
owner ref check failed [2478014939136 16384]
ref mismatch on [2478015250432 16384] extent item 0, found 1
Backref 2478015250432 parent 27641 root 27641 not found in extent tree
backpointer mismatch on [2478015250432 16384]
ref mismatch on [2478640545792 16384] extent item 0, found 1
Backref 2478640545792 parent 27641 root 27641 not found 

Re: [PATCH 0/6] add sanity check for extent inline ref type

[Ivan Sizov]

2017-06-01 20:35 GMT+03:00 Liu Bo <bo.li@oracle.com>:
> After I went through the output of leaf's content, most parts of the
> leaf is sane except the two corrupted items, it's still not clear to
> me what caused the corruption, there could be some corner cases that
> I'm not aware of.
>
> If fsck doesn't work for you, then a recovery from backup may be the
> best option.

I don't need to run any repair procedures because system is working
normally. Most likely that corrupted extents belong to files located
somewhere in /home.
Do you mean I should run fsck in order to determine which files are
corrupted? What are proper options to run fsck with?

-- 
Ivan Sizov
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/6] add sanity check for extent inline ref type

[Ivan Sizov]

2017-05-30 21:02 GMT+03:00 Liu Bo <bo.li@oracle.com>:
> On Tue, May 30, 2017 at 05:05:09PM +0300, Ivan Sizov wrote:
>> 2017-05-26 3:26 GMT+03:00 Liu Bo <bo.li@oracle.com>:
>> >Patch 6 adds scrub support to detect the corruption, so users can be
>> noticed when they do scrub on a regular basis.
>> >I'm not sure in the real world what may result in this corruption
>>
>> I've caught this type of corruption in the wild. The big rsync backup
>> always ends with a kernel crash due to BUG() statement in
>> ctime.h:1779. After applying this patchset and running scrub I've got
>> following messages:
>>
>> [sivan@fruestuck ~]$ dmesg | grep "invalid extent inline"
>> [ 8812.428673] eb 4631634034688(tree block) invalid extent inline ref type 0
>> [ 8812.429148] BTRFS error (device sdb1): scrub: extent
>> 2994741510144(0x2b94481) has an invalid extent inline ref type,
>> ignored.
>> [ 8812.430086] eb 4631634034688(tree block) invalid extent inline ref type 0
>> [ 8812.430569] BTRFS error (device sdb1): scrub: extent
>> 2994741559296(0x2b94481c000) has an invalid extent inline ref type,
>> ignored.
>>
>> How to find the cause of the corruption? Should I try to fix it, or it
>> is not dangerous for the filesystem? If I should, how to do that?
>
> Did it also print a btree's leaf's content?  If yes, it could show us
> which inline ref has the issue.

Yes, it does.

[ cut here ]
WARNING: CPU: 0 PID: 14133 at fs/btrfs/scrub.c:2506
scrub_stripe+0xe6f/0x1170 [btrfs]
Modules linked in: veth xt_nat ipt_MASQUERADE nf_nat_masquerade_ipv4
xt_addrtype br_netfilter nf_conntrack_netbios_ns
nf_conntrack_broadcast nf_conntrack_ftp xt_CT ip6t_rpfilter
ip6t_REJECT nf_reject_ipv6 ip_set nfnetlink ebtable_nat ebtable_broute
bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6
nf_nat_ipv6 ip6table_mangle ip6table_raw ip6table_security iptable_nat
nf_nat_ipv4 nf_nat iptable_mangle iptable_raw iptable_security
ebtable_filter ebtables nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack
nf_conntrack libcrc32c ip6table_filter ip6_tables intel_powerclamp
coretemp kvm_intel kvm snd_hda_codec_realtek snd_hda_codec_generic
irqbypass snd_hda_intel intel_cstate snd_hda_codec intel_uncore ppdev
snd_hda_core snd_hwdep iTCO_wdt iTCO_vendor_support mei_wdt gpio_ich
snd_seq
 snd_seq_device snd_pcm snd_timer snd soundcore tpm_infineon mei_me
mei acpi_cpufreq tpm_tis parport_pc parport i2c_i801 tpm_tis_core
shpchp tpm lpc_ich nfsd auth_rpcgss nfs_acl lockd grace sunrpc
binfmt_misc btrfs hid_logitech_hidpp xor i915 raid6_pq crc32c_intel
video i2c_algo_bit drm_kms_helper serio_raw drm hid_logitech_dj uas
usb_storage r8169 mii
CPU: 0 PID: 14133 Comm: btrfs Not tainted
4.11.3-200.local.btrfs_patched.fc25.x86_64 #1
Hardware name: MSI MS-7636/H55M-P31(MS-7636)   , BIOS V1.9 09/14/2010
Call Trace:
 dump_stack+0x63/0x86
 __warn+0xcb/0xf0
 warn_slowpath_null+0x1d/0x20
 scrub_stripe+0xe6f/0x1170 [btrfs]
 scrub_chunk+0x102/0x140 [btrfs]
 ? scrub_chunk+0x102/0x140 [btrfs]
 scrub_enumerate_chunks+0x300/0x680 [btrfs]
 ? wake_atomic_t_function+0x60/0x70
 btrfs_scrub_dev+0x213/0x540 [btrfs]
 ? __mnt_want_write+0x56/0x60
 btrfs_ioctl+0x1351/0x2470 [btrfs]
 do_vfs_ioctl+0xa3/0x5f0
 ? do_vfs_ioctl+0xa3/0x5f0
 ? security_file_ioctl+0x43/0x60
 SyS_ioctl+0x79/0x90
 do_syscall_64+0x67/0x180
 entry_SYSCALL64_slow_path+0x25/0x25
RIP: 0033:0x7fa688cc4787
RSP: 002b:7fa6873c2d58 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 5572d3db7190 RCX: 7fa688cc4787
RDX: 5572d3db7190 RSI: c400941b RDI: 0003
RBP:  R08: 7fa6873c3700 R09: 
R10: 7fa6873c3700 R11: 0246 R12: 7fa6873c3500
R13: 7ffc22fb28ef R14: 7fa6873c39c0 R15: 7fa6873c3700
---[ end trace 70deff6b302d4408 ]---
BTRFS info (device sdb1): leaf 2994891669504 total ptrs 121 free space 8284
item 0 key (2994739920896 169 0) itemoff 16250 itemsize 33
extent refs 1 gen 833513 flags 258
shared block backref parent 4026278117376
item 1 key (2994739937280 169 0) itemoff 16217 itemsize 33
extent refs 1 gen 1389730 flags 2
tree block backref root 1429
item 2 key (2994739953664 169 0) itemoff 16184 itemsize 33
extent refs 1 gen 1389730 flags 2
tree block backref root 1429
item 3 key (2994739970048 169 0) itemoff 16151 itemsize 33
extent refs 1 gen 1417250 flags 2
tree block backref root 1451
item 4 key (2994739986432 169 0) itemoff 16118 itemsize 33
extent refs 1 gen 826970 flags 2
tree block backref root 7
item 5 key (2994740002816 169 0) itemoff 16085 itemsize 33
extent refs 1 gen 9

Re: [PATCH 0/6] add sanity check for extent inline ref type

[Ivan Sizov]

2017-05-26 3:26 GMT+03:00 Liu Bo :
>Patch 6 adds scrub support to detect the corruption, so users can be
noticed when they do scrub on a regular basis.
>I'm not sure in the real world what may result in this corruption

I've caught this type of corruption in the wild. The big rsync backup
always ends with a kernel crash due to BUG() statement in
ctime.h:1779. After applying this patchset and running scrub I've got
following messages:

[sivan@fruestuck ~]$ dmesg | grep "invalid extent inline"
[ 8812.428673] eb 4631634034688(tree block) invalid extent inline ref type 0
[ 8812.429148] BTRFS error (device sdb1): scrub: extent
2994741510144(0x2b94481) has an invalid extent inline ref type,
ignored.
[ 8812.430086] eb 4631634034688(tree block) invalid extent inline ref type 0
[ 8812.430569] BTRFS error (device sdb1): scrub: extent
2994741559296(0x2b94481c000) has an invalid extent inline ref type,
ignored.

How to find the cause of the corruption? Should I try to fix it, or it
is not dangerous for the filesystem? If I should, how to do that?
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Can't remount a BTRFS partition read write after a drive failure

[Ivan Sizov]

2017-05-16 15:56 GMT+03:00 Sylvain Leroux <sylv...@chicoree.fr>:
>
>
> The drive is not reliable. And I noticed when there is an error and the
> USB device appears to be dead to the kernel, I am later unable to
> remount rw the drive. I can mount it read only though.
>
> This seems to be a systematic behavior. And it occasionally happens when
> the computer wake up from sleep and the drive is still attached.
>
> Power cycling the disk do not change anything, but restarting the
> computer "solves" the issue.

(Maybe offtop) Seems like your disk's USB-SATA controller is almost
dead. You shouldn't further use it with USB because this lead to data
corruption. Detach HDD from case and plug directly to a SATA port or
replace the controller.

--
Ivan Sizov
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Strange behavior after "rm -rf //"

[Ivan Sizov]

Duncan, you was right. The commit didn't happen and nothing was
deleted except ext4 /boot. the System booted normally after GRUB2 and
kernel recovery.

Thank you much.

P.S. I'm sorry for the late answer.

2016-08-09 23:30 GMT+03:00 Duncan <1i5t5.dun...@cox.net>:
> Chris Murphy posted on Tue, 09 Aug 2016 11:10:08 -0600 as excerpted:
>
>> On Mon, Aug 8, 2016 at 12:38 PM, Ivan Sizov <sivan...@gmail.com> wrote:
>>> 2016-08-08 20:13 GMT+03:00 Chris Murphy <li...@colorremedies.com>:
>>>> Just a wild guess, the deletions may be in the tree log and haven't
>>>> been applied to the other trees (fs tree, extent tree, etc). So yes
>>>> I'd expect they get deleted on a rw mount.
>>>>
>>>> This is what kernel? Because kernel 4.6 offers mount option
>>>> "nologreplay" which suggests even if you do mount -r that log replay
>>>> happens, so you shouldn't see these deleted files unless you mount ro
>>>> *and* use nologreplay mount option.
>>>
>>> Live USB has kernel 4.5.7. Maybe I should try to run "btrfs rescue
>>> zero-log" and then mount RW? Will the files safe in that case?
>>
>> Depends on what's in the log that you're zeroing out. It's entirely
>> possible other things are lost, not just the incomplete deletion. And
>> also I have no idea if the deletion is entirely contained in only the
>> tree log.
>
> It's worth noting a critical difference between btrfs replay logs and
> conventional filesystem replay logs, however, with the result being that
> there's a fair chance the log replay has absolutely nothing to do with
> this case at all, and that it's simply commit vs. crash timing.
>
> Btrfs is copy-on-write, with commits designed to be atomic -- changes
> work their way up the tree until a root commit finalizes them, and if a
> crash occurs, all changes since the last successful commit (with a commit
> every 30 seconds by default, and a mount option to change that) are
> normally lost.  Because the filesystem is copy-on-write, that means the
> filesystem should be consistent at that commit, and changes made after
> that will be in different locations that haven't made it into the tree
> yet, since the next commit wasn't able to happen due to the crash.  Thus,
> the stuff that conventional filesystems log simply doesn't apply to btrfs
> at all.
>
> By contrast, conventional filesystems rewrite a lot of data and metadata
> in-place, and logging lets them write out to a temporary area the changes
> they intend to make before they actually write them to the permanent
> location, so that in the event of a crash, any data partially written to
> the permanent location will be replayed from the log, while if the crash
> happened when writing the log so it's corrupt, that record won't be
> replayed, and the old content will remain in place.
>
> Tho of course writing all data twice tends to hit performance rather
> hard, so what most event logging filesystems do is only log the metadata,
> not the actual data.  This lets them be much faster than if they were
> logging the data, and normally protects the filesystem structure, but
> there's some chance that files rewritten in-place will be corrupt if a
> crash happens at the wrong moment.  But it limits the damage to only the
> file being written at the time, and does away with the requirement to fsck
> the entire filesystem after every crash.
>
> So what /does/ the btrfs log do, then?  Good question! =:^)  Rather
> simply, keeping in mind that commits only normally trigger every 30
> seconds, the btrfs log tracks fsyncs (individual file syncs, as opposed
> to whole filesystem syncs), recording them in a replay log, so the
> filesystem can return success on the fsync, that the file was actually
> synced to permanent storage (often ssds these days, so not always "disk"
> as it used to be), without having to either wait upto 30 seconds for the
> next root tree commit, or forcing a full filesystem sync and commit,
> possibly including many other files, when only the one was requested.
>
> So with btrfs, it's *only* fsyncs that are logged to the replay log, and
> that only to be able to truthfully return that the file was written to
> permanent storage, not normal filesystem operations, which are already
> atomic due to the copy-on-write semantics, and thus don't need logged.
>
> So then, the question becomes one of whether rm -rf, or whatever other
> actual command was used to do the deletes, called fsync, or not.  If the
> command didn't call fsync, then it would have been the normal btrfs
> commit mechanism, again, every 30 seconds by default, that would have
> been in play here, and the b

Re: Strange behavior after "rm -rf //"

[Ivan Sizov]

2016-08-08 21:52 GMT+03:00 Hugo Mills <h...@carfax.org.uk>:
> On Mon, Aug 08, 2016 at 09:38:28PM +0300, Ivan Sizov wrote:
>> P.S. IMHO, log replay by default is a quite dangerous thing. I didn't
>> know about that change and I could lose all files if the live USB had
>> 4.6 kernel))
>
>Log reply on mount has _always_ been the default, and should remain
> so. It gives you the expected semantics after a power loss: all th
> efiles that you'd written up to the point of the power loss actually
> appear afterwards. (If this didn't happen, you could lose up to 30s of
> writes from before the crash).
>
>It's only very recently that there's been an option to prevent it,
> which is useful in a limited number of cases (such as trying to
> undelete a file, which is not really a supported operation in any
> case).

I mean only RO mount, of course.

So, will zero-log prevent my files during RW mount?


-- 
Ivan Sizov (SIvan)
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Strange behavior after "rm -rf //"

[Ivan Sizov]

2016-08-08 20:13 GMT+03:00 Chris Murphy <li...@colorremedies.com>:
> Just a wild guess, the deletions may be in the tree log and haven't
> been applied to the other trees (fs tree, extent tree, etc). So yes
> I'd expect they get deleted on a rw mount.
>
> This is what kernel? Because kernel 4.6 offers mount option
> "nologreplay" which suggests even if you do mount -r that log replay
> happens, so you shouldn't see these deleted files unless you mount ro
> *and* use nologreplay mount option.

Live USB has kernel 4.5.7. Maybe I should try to run "btrfs rescue
zero-log" and then mount RW? Will the files safe in that case?

> Anyway, even 5 seconds of rm -rf damages too much. If you don't have
> recent snapshots then it's not sanely salvageable, just reinstall.

As I could see, almost all the "deleted" files are present. Certainly,
I'll make an rsync diff between two-week-ago snapshot and the current
FS state. But it will better if in-place recover without backup is
possible.

P.S. IMHO, log replay by default is a quite dangerous thing. I didn't
know about that change and I could lose all files if the live USB had
4.6 kernel))

-- 
Ivan Sizov (SIvan)
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Strange behavior after "rm -rf //"

[Ivan Sizov]

I'd ran "rm -rf //" by mistake two days ago. I'd stopped it after five
seconds, but some files had been deleted. I'd tried to shutdown the
system, but couldn't (a lot of files in /bin had been deleted and
systemd didn't work). After hard reboot (by reset button) and booting
to a live USB a strange thing was discovered.

Deleted files are present when I "mount -r" the disk, but
btrfs-restore tells they are deleted ("We have looped trying to
restore files too many times to be making progress").

What does it mean? Will those files be deleted after RW mount?

-- 
Ivan Sizov (SIvan)
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Determine the creation time of a root tree

[Ivan Sizov]

Is there a way to know when the root tree or generation was created?
btrfs-find-root doesn't have such option.

--
Ivan Sizov (SIvan)
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Will "btrfs check --repair" fix the mounting problem?

[Ivan Sizov]

2015-12-15 1:42 GMT+00:00 Qu Wenruo <quwen...@cn.fujitsu.com>:
> You'll see output like the following:
> Well block 29491200(gen: 5 level: 0) seems good, and it matches superblock
> Well block 29376512(gen: 4 level: 0) seems good, but generation/level
> doesn't match, want gen: 5 level: 0
>
> The match one is not what you're looking for.
> Try the one whose generation is a little smaller than match one.
>
> Then use btrfsck to test if it's OK:
> $ btrfsck -r  /dev/sda1
>
> Try 2~5 times with bytenr whose generation is near the match one.
> If you're in good luck, you will find one doesn't crash btrfsck.
>
> And if that doesn't produce much error, then you can try btrfsck --repair -r
>  to fix it and try mount.

I've found a root that doesn't produce backtrace. But extent/chunk
allocation errors was found:

$ sudo btrfsck --tree-root 535461888 /dev/sda1
parent transid verify failed on 535461888 wanted 21154 found 21150
parent transid verify failed on 535461888 wanted 21154 found 21150
Ignoring transid failure
checking extents
parent transid verify failed on 459292672 wanted 21148 found 21153
parent transid verify failed on 459292672 wanted 21148 found 21153
Ignoring transid failure
bad block 459292672
Errors found in extent allocation tree or chunk allocation
parent transid verify failed on 459292672 wanted 21148 found 21153

Should I ignore those errors and run btrfsck --repair? Or
--init-extent-tree is needed?

-- 
Ivan Sizov
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Will "btrfs check --repair" fix the mounting problem?

[Ivan Sizov]

2015-12-14 5:28 GMT+03:00 Qu Wenruo <quwen...@cn.fujitsu.com>:
> Not completely sure, but it may be related to a regression in 4.2.
> The regression it self is already fixed, but is not backported to 4.2 as far
> as I know.
>
> So, I'd recommend to revert to 4.1 and see if things get better.
> Fortunately, btrfs already aborted the transaction before things get worse.

Nothing changed, mount also fails on 4.1.3.


>>> I checked the filesystem extents:
>>>
>>> $ sudo btrfs check --subvol-extents 5 /dev/sda1
>>> Print extent state for subvolume 5 on /dev/sda1
>>> UUID: 6de5c663-bc65-4120-8cf6-5309fd25aa7e
>>> checksum verify failed on 159708168192 found 3659C180 wanted 8EE67C14
>>> checksum verify failed on 159708168192 found 3659C180 wanted 8EE67C14
>>> bytenr mismatch, want=159708168192, have=16968404070778227820
>>> ERROR: while mapping refs: -5
>>> extent_io.c:582: free_extent_buffer: Assertion `eb->refs < 0` failed.
>>> btrfs(+0x51e9e)[0x56283f4bde9e]
>>> btrfs(free_extent_buffer+0xc0)[0x56283f4be9b0]
>>> btrfs(btrfs_free_fs_root+0x11)[0x56283f4aef11]
>>> btrfs(rb_free_nodes+0x21)[0x56283f4d7cc1]
>>> btrfs(close_ctree+0x194)[0x56283f4b0214]
>>> btrfs(cmd_check+0x486)[0x56283f49ace6]
>>> btrfs(main+0x82)[0x56283f47fad2]
>>> /lib64/libc.so.6(__libc_start_main+0xf0)[0x7f8cbea98580]
>>> btrfs(_start+0x29)[0x56283f47fbd9]
>>> $
>
>
> Did you tried it without the '--subvol-extents 5' options?
> And what's the output?

Yes, I tried it. The output is normal, nothing problem found (shows
UUID, then "checking extents" and that's all)!

> And it may be a good idea to run btrfs-find-root -a, trying to find a good
> copy of old btrfs root tree.
> It may cause miracle to make it RW again.

Thanks for advice. "btrfs-find-root -a" is running at the moment. What
should I do after its completion? Should I just try RW mounting of the
found root or it isn't safe?

> +1 for the advice if you just want to use back up things and get back to
> normal life.

I already backed up the most important data (the whole disk space is
1,82 TB). But I want to solve this strange problem.


-- 
Ivan Sizov
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Determine is file a reflink or not

[Ivan Sizov]

Is there a way to view the CoW structure, e.g. to know is file just a
reflink or it was modified? I copied many files from snapshot with
--reflink=always I and want to know which files was modified since the
copying. Calculating hashsums seems to be too long thing.

-- 
Ivan Sizov
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Will "btrfs check --repair" fix the mounting problem?

[Ivan Sizov]

2015-12-11 21:24 GMT+03:00 Chris Murphy :
> I would not repair it if the risk of it getting worse is bad for your data.
>
> Note the wiki says this feature is not well tested and is reported to
> not work reliably.
> https://btrfs.wiki.kernel.org/index.php/Conversion_from_Ext3
>
> Qu is working on patches to fix some of these problems, I don't know
> the status of any of that. I just did a conversion myself the other
> day with kernel 4.4.0rc3 and btrfs-progs 4.3.1 and that worked without
> error. But there were also no big files at all (it was just a clean OS
> installation). I immediately took a snapshot of that, and btrfs
> send/receive it to a new Btrfs volume, and then discarded the
> converted one entirely.
>
> The trace looks like it's mounting read-only? If it can be mounted
> read only, get the important data off the volume if it's not already
> backed up, and then blow it away. I personally wouldn't bother with
> repairing it.

What is the better way to get data? send/receive works only with RO
snapshots. Is there another way to preserve subvolumes and CoW
structure (a lot of files was copied between subvols using "cp
--reflink=always")? Or just rsync'ing files is all what I can do?
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Will "btrfs check --repair" fix the mounting problem?

[Ivan Sizov]

Btrfs crashes in few seconds after mounting RW.
If it's important: the volume was converted from ext4. "ext2_saved"
subvolume still presents.

dmesg:
[  625.998387] BTRFS info (device sda1): disk space caching is enabled
[  625.998392] BTRFS: has skinny extents
[  627.727708] BTRFS: checking UUID tree
[  708.514128] [ cut here ]
[  708.514161] WARNING: CPU: 1 PID: 2263 at fs/btrfs/extent-tree.c:6255 
__btrfs_free_extent.isra.68+0x8c8/0xd70 [btrfs]()
[  708.514164] Modules linked in: bnep bluetooth rfkill ip6t_rpfilter 
ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_broute bridge ebtable_filter 
ebtable_nat ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 
ip6table_raw ip6table_security ip6table_mangle ip6table_filter ip6_tables 
iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack 
iptable_raw iptable_security iptable_mangle gpio_ich coretemp kvm_intel kvm 
iTCO_wdt iTCO_vendor_support snd_hda_codec_realtek snd_hda_codec_generic 
snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device 
lpc_ich snd_pcm snd_timer ppdev snd i2c_i801 mei_me mei soundcore parport_pc 
parport shpchp tpm_infineon tpm_tis tpm acpi_cpufreq nfsd auth_rpcgss nfs_acl 
lockd grace isofs squashfs btrfs xor raid6_pq i915 hid_logitech_hidpp
[  708.514277]  8021q garp stp video llc mrp i2c_algo_bit drm_kms_helper r8169 
uas crc32c_intel drm serio_raw mii hid_logitech_dj usb_storage scsi_dh_rdac 
scsi_dh_emc scsi_dh_alua sunrpc loop
[  708.514311] CPU: 1 PID: 2263 Comm: btrfs-transacti Not tainted 
4.2.3-300.fc23.x86_64 #1
[  708.514315] Hardware name: MSI MS-7636/H55M-P31(MS-7636)   , BIOS V1.9 
09/14/2010
[  708.514319]   f50458a6 880066b03ad8 
81771fca
[  708.514326]    880066b03b18 
8109e4a6
[  708.514332]  0002 00252f595000 fffe 

[  708.514338] Call Trace:
[  708.514349]  [] dump_stack+0x45/0x57
[  708.514359]  [] warn_slowpath_common+0x86/0xc0
[  708.514365]  [] warn_slowpath_null+0x1a/0x20
[  708.514391]  [] __btrfs_free_extent.isra.68+0x8c8/0xd70 
[btrfs]
[  708.514429]  [] ? find_ref_head+0x5a/0x80 [btrfs]
[  708.514456]  [] __btrfs_run_delayed_refs+0x998/0x1080 
[btrfs]
[  708.514477]  [] btrfs_run_delayed_refs.part.73+0x74/0x270 
[btrfs]
[  708.514496]  [] btrfs_run_delayed_refs+0x15/0x20 [btrfs]
[  708.514518]  [] btrfs_commit_transaction+0x56/0xad0 [btrfs]
[  708.514541]  [] transaction_kthread+0x214/0x230 [btrfs]
[  708.514564]  [] ? btrfs_cleanup_transaction+0x500/0x500 
[btrfs]
[  708.514569]  [] kthread+0xd8/0xf0
[  708.514574]  [] ? kthread_worker_fn+0x160/0x160
[  708.514581]  [] ret_from_fork+0x3f/0x70
[  708.514585]  [] ? kthread_worker_fn+0x160/0x160
[  708.514588] ---[ end trace 673f3bf2295a ]---
[  708.514594] BTRFS info (device sda1): leaf 535035904 total ptrs 204 free 
space 4451
[  708.514598]  item 0 key (159696797696 169 0) itemoff 16250 itemsize 33
[  708.514601]  extent refs 1 gen 21134 flags 2
[  708.514604]  tree block backref root 2
[  708.514609]  item 1 key (159696830464 169 1) itemoff 16217 itemsize 33
[  708.514612]  extent refs 1 gen 21134 flags 2
[  708.514615]  tree block backref root 2
[  708.514619]  item 2 key (159696846848 169 0) itemoff 16184 itemsize 33

*** a lot of similar messages ***

[  708.516923]  item 203 key (159711268864 169 0) itemoff 9551 itemsize 33
[  708.516927]  extent refs 1 gen 21082 flags 2
[  708.516930]  tree block backref root 384
[  708.516937] BTRFS error (device sda1): unable to find ref byte nr 
159708172288 parent 0 root 385  owner 2 offset 0
[  708.516944] [ cut here ]
[  708.516975] WARNING: CPU: 1 PID: 2263 at fs/btrfs/extent-tree.c:6261 
__btrfs_free_extent.isra.68+0x92f/0xd70 [btrfs]()
[  708.516979] BTRFS: Transaction aborted (error -2)
[  708.516982] Modules linked in: bnep bluetooth rfkill ip6t_rpfilter 
ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_broute bridge ebtable_filter 
ebtable_nat ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 
ip6table_raw ip6table_security ip6table_mangle ip6table_filter ip6_tables 
iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack 
iptable_raw iptable_security iptable_mangle gpio_ich coretemp kvm_intel kvm 
iTCO_wdt iTCO_vendor_support snd_hda_codec_realtek snd_hda_codec_generic 
snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device 
lpc_ich snd_pcm snd_timer ppdev snd i2c_i801 mei_me mei soundcore parport_pc 
parport shpchp tpm_infineon tpm_tis tpm acpi_cpufreq nfsd auth_rpcgss nfs_acl 
lockd grace isofs squashfs btrfs xor raid6_pq i915 hid_logitech_hidpp
[  708.517075]  8021q garp stp video llc mrp i2c_algo_bit drm_kms_helper r8169 
uas crc32c_intel drm serio_raw mii hid_logitech_dj usb_storage scsi_dh_rdac 
scsi_dh_emc scsi_dh_alua sunrpc loop
[  708.517108] CPU: