btrfs check: add_missing_dir_index: BUG_ON `ret` triggered, value -17

btrfs check: add_missing_dir_index: BUG_ON `ret` triggered, value -17

[Marc MERLIN]

Howdy,

Up to date git pull from btrfs-progs:

gargamel:~# btrfs check --repair /dev/mapper/raid0d1
enabling repair mode
Checking filesystem on /dev/mapper/raid0d1
UUID: 01334b81-c0db-4e80-92e4-cac4da867651
checking extents
corrupt extent record: key 203003699200 168 40960
corrupt extent record: key 203003764736 168 172032
ref mismatch on [203003699200 40960] extent item 0, found 1
Data backref 203003699200 root 258 owner 1933897829 offset 0 num_refs 0 not found in extent tree
Incorrect local backref count on 203003699200 root 258 owner 1933897829 offset 0 found 1 wanted 0 back 0x5596988c2130
backpointer mismatch on [203003699200 40960]
repair deleting extent record: key 203003699200 168 40960
adding new data backref on 203003699200 root 258 owner 1933897829 offset 0 found 1
Repaired extent references for 203003699200
Data backref 203003764736 root 258 owner 1932315368 offset 0 num_refs 0 not found in extent tree
Incorrect local backref count on 203003764736 root 258 owner 1932315368 offset 0 found 1 wanted 0 back 0x5596dde358f0
backpointer mismatch on [203003764736 172032]
repair deleting extent record: key 203003764736 168 172032
adding new data backref on 203003764736 root 258 owner 1932315368 offset 0 found 1
Repaired extent references for 203003764736
Fixed 0 roots.
checking free space cache
cache and super generation don't match, space cache will be invalidated
checking fs roots
invalid location in dir item 0
Deleting bad dir index [1919785864,96,1958] root 258
Deleting bad dir index [1919785864,96,1957] root 258
repairing missing dir index item for inode 1919805647
cmds-check.c:2614: add_missing_dir_index: BUG_ON `ret` triggered, value -17
btrfs(+0x52207)[0x55966a6fa207]
btrfs(+0x5225a)[0x55966a6fa25a]
btrfs(+0x5cef3)[0x55966a704ef3]
btrfs(cmd_check+0x2e10)[0x55966a70ea35]
btrfs(main+0x85)[0x55966a6b9dc3]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f794aadf2b1]
btrfs(_start+0x2a)[0x55966a6b993a]
Aborted

-- 
"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/  

Re: btrfs check: add_missing_dir_index: BUG_ON `ret` triggered, value -17

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 2355 bytes --]



On 2017年11月17日 10:26, Marc MERLIN wrote:
> Howdy,
> 
> Up to date git pull from btrfs-progs:
> 
> gargamel:~# btrfs check --repair /dev/mapper/raid0d1
> enabling repair mode
> Checking filesystem on /dev/mapper/raid0d1
> UUID: 01334b81-c0db-4e80-92e4-cac4da867651
> checking extents
> corrupt extent record: key 203003699200 168 40960
> corrupt extent record: key 203003764736 168 172032
> ref mismatch on [203003699200 40960] extent item 0, found 1
> Data backref 203003699200 root 258 owner 1933897829 offset 0 num_refs 0 not found in extent tree
> Incorrect local backref count on 203003699200 root 258 owner 1933897829 offset 0 found 1 wanted 0 back 0x5596988c2130
> backpointer mismatch on [203003699200 40960]
> repair deleting extent record: key 203003699200 168 40960
> adding new data backref on 203003699200 root 258 owner 1933897829 offset 0 found 1
> Repaired extent references for 203003699200
> Data backref 203003764736 root 258 owner 1932315368 offset 0 num_refs 0 not found in extent tree
> Incorrect local backref count on 203003764736 root 258 owner 1932315368 offset 0 found 1 wanted 0 back 0x5596dde358f0
> backpointer mismatch on [203003764736 172032]
> repair deleting extent record: key 203003764736 168 172032
> adding new data backref on 203003764736 root 258 owner 1932315368 offset 0 found 1
> Repaired extent references for 203003764736
> Fixed 0 roots.
> checking free space cache
> cache and super generation don't match, space cache will be invalidated
> checking fs roots
> invalid location in dir item 0
> Deleting bad dir index [1919785864,96,1958] root 258
> Deleting bad dir index [1919785864,96,1957] root 258
> repairing missing dir index item for inode 1919805647
> cmds-check.c:2614: add_missing_dir_index: BUG_ON `ret` triggered, value -17

-EEXIST. Btrfs check --repair is trying to re-insert some key which
exists already.

Would you please provide the output of "btrfs-debug-tree -t 258 | grep
1919805647" to help the debugging?

Thanks,
Qu

> btrfs(+0x52207)[0x55966a6fa207]
> btrfs(+0x5225a)[0x55966a6fa25a]
> btrfs(+0x5cef3)[0x55966a704ef3]
> btrfs(cmd_check+0x2e10)[0x55966a70ea35]
> btrfs(main+0x85)[0x55966a6b9dc3]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f794aadf2b1]
> btrfs(_start+0x2a)[0x55966a6b993a]
> Aborted
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 520 bytes --]

Re: btrfs check: add_missing_dir_index: BUG_ON `ret` triggered, value -17

[Marc MERLIN]

On Fri, Nov 17, 2017 at 01:17:19PM +0800, Qu Wenruo wrote:
> 
> 
> On 2017年11月17日 10:26, Marc MERLIN wrote:
> > Howdy,
> > 
> > Up to date git pull from btrfs-progs:
> > 
> > gargamel:~# btrfs check --repair /dev/mapper/raid0d1
> > enabling repair mode
> > Checking filesystem on /dev/mapper/raid0d1
> > UUID: 01334b81-c0db-4e80-92e4-cac4da867651
> > checking extents
> > corrupt extent record: key 203003699200 168 40960
> > corrupt extent record: key 203003764736 168 172032
> > ref mismatch on [203003699200 40960] extent item 0, found 1
> > Data backref 203003699200 root 258 owner 1933897829 offset 0 num_refs 0 not found in extent tree
> > Incorrect local backref count on 203003699200 root 258 owner 1933897829 offset 0 found 1 wanted 0 back 0x5596988c2130
> > backpointer mismatch on [203003699200 40960]
> > repair deleting extent record: key 203003699200 168 40960
> > adding new data backref on 203003699200 root 258 owner 1933897829 offset 0 found 1
> > Repaired extent references for 203003699200
> > Data backref 203003764736 root 258 owner 1932315368 offset 0 num_refs 0 not found in extent tree
> > Incorrect local backref count on 203003764736 root 258 owner 1932315368 offset 0 found 1 wanted 0 back 0x5596dde358f0
> > backpointer mismatch on [203003764736 172032]
> > repair deleting extent record: key 203003764736 168 172032
> > adding new data backref on 203003764736 root 258 owner 1932315368 offset 0 found 1
> > Repaired extent references for 203003764736
> > Fixed 0 roots.
> > checking free space cache
> > cache and super generation don't match, space cache will be invalidated
> > checking fs roots
> > invalid location in dir item 0
> > Deleting bad dir index [1919785864,96,1958] root 258
> > Deleting bad dir index [1919785864,96,1957] root 258
> > repairing missing dir index item for inode 1919805647
> > cmds-check.c:2614: add_missing_dir_index: BUG_ON `ret` triggered, value -17
> 
> -EEXIST. Btrfs check --repair is trying to re-insert some key which
> exists already.
> 
> Would you please provide the output of "btrfs-debug-tree -t 258 | grep
> 1919805647" to help the debugging?
 
Sure. It may run all night and I'm going to bed now, but the output I
got so far, is:
gargamel:~# btrfs-debug-tree -t 258 /dev/mapper/raid0d1 | grep 1919805647
                location key (1919805647 INODE_ITEM 0) type FILE
        item 30 key (1919805647 INODE_ITEM 0) itemoff 14415 itemsize 160
        item 31 key (1919805647 INODE_REF 1919785864) itemoff 14389 itemsize 26
        item 32 key (1919805647 EXTENT_DATA 0) itemoff 14336 itemsize 53
(...)

I'll post tomorrow if I get more overnight

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

Re: btrfs check: add_missing_dir_index: BUG_ON `ret` triggered, value -17

[Marc MERLIN]

Here's the whole output:
gargamel:~# btrfs-debug-tree -t 258 /dev/mapper/raid0d1 | grep 1919805647
                location key (1919805647 INODE_ITEM 0) type FILE
        item 30 key (1919805647 INODE_ITEM 0) itemoff 14415 itemsize 160
        item 31 key (1919805647 INODE_REF 1919785864) itemoff 14389 itemsize 26
        item 32 key (1919805647 EXTENT_DATA 0) itemoff 14336 itemsize 53
parent transid verify failed on 1173964603392 wanted 2244945 found 2247404
parent transid verify failed on 1173964603392 wanted 2244945 found 2247404
parent transid verify failed on 1173964603392 wanted 2244945 found 2247404
parent transid verify failed on 1173964603392 wanted 2244945 found 2247404
Ignoring transid failure
parent transid verify failed on 1652248100864 wanted 2245186 found 2247494
parent transid verify failed on 1652248100864 wanted 2245186 found 2247494
parent transid verify failed on 1652248100864 wanted 2245186 found 2247494
parent transid verify failed on 1652248100864 wanted 2245186 found 2247494
Ignoring transid failure
parent transid verify failed on 1174605512704 wanted 2245171 found 2247435
parent transid verify failed on 1174605512704 wanted 2245171 found 2247435
parent transid verify failed on 1174605512704 wanted 2245171 found 2247435
parent transid verify failed on 1174605512704 wanted 2245171 found 2247435
Ignoring transid failure
WARNING: eb corrupted: item 130 eb level 0 next level 2, skipping the rest


On Thu, Nov 16, 2017 at 10:17:07PM -0800, Marc MERLIN wrote:
> On Fri, Nov 17, 2017 at 01:17:19PM +0800, Qu Wenruo wrote:
> > 
> > 
> > On 2017年11月17日 10:26, Marc MERLIN wrote:
> > > Howdy,
> > > 
> > > Up to date git pull from btrfs-progs:
> > > 
> > > gargamel:~# btrfs check --repair /dev/mapper/raid0d1
> > > enabling repair mode
> > > Checking filesystem on /dev/mapper/raid0d1
> > > UUID: 01334b81-c0db-4e80-92e4-cac4da867651
> > > checking extents
> > > corrupt extent record: key 203003699200 168 40960
> > > corrupt extent record: key 203003764736 168 172032
> > > ref mismatch on [203003699200 40960] extent item 0, found 1
> > > Data backref 203003699200 root 258 owner 1933897829 offset 0 num_refs 0 not found in extent tree
> > > Incorrect local backref count on 203003699200 root 258 owner 1933897829 offset 0 found 1 wanted 0 back 0x5596988c2130
> > > backpointer mismatch on [203003699200 40960]
> > > repair deleting extent record: key 203003699200 168 40960
> > > adding new data backref on 203003699200 root 258 owner 1933897829 offset 0 found 1
> > > Repaired extent references for 203003699200
> > > Data backref 203003764736 root 258 owner 1932315368 offset 0 num_refs 0 not found in extent tree
> > > Incorrect local backref count on 203003764736 root 258 owner 1932315368 offset 0 found 1 wanted 0 back 0x5596dde358f0
> > > backpointer mismatch on [203003764736 172032]
> > > repair deleting extent record: key 203003764736 168 172032
> > > adding new data backref on 203003764736 root 258 owner 1932315368 offset 0 found 1
> > > Repaired extent references for 203003764736
> > > Fixed 0 roots.
> > > checking free space cache
> > > cache and super generation don't match, space cache will be invalidated
> > > checking fs roots
> > > invalid location in dir item 0
> > > Deleting bad dir index [1919785864,96,1958] root 258
> > > Deleting bad dir index [1919785864,96,1957] root 258
> > > repairing missing dir index item for inode 1919805647
> > > cmds-check.c:2614: add_missing_dir_index: BUG_ON `ret` triggered, value -17
> > 
> > -EEXIST. Btrfs check --repair is trying to re-insert some key which
> > exists already.
> > 
> > Would you please provide the output of "btrfs-debug-tree -t 258 | grep
> > 1919805647" to help the debugging?
>  
> Sure. It may run all night and I'm going to bed now, but the output I
> got so far, is:
> gargamel:~# btrfs-debug-tree -t 258 /dev/mapper/raid0d1 | grep 1919805647
>                 location key (1919805647 INODE_ITEM 0) type FILE
>         item 30 key (1919805647 INODE_ITEM 0) itemoff 14415 itemsize 160
>         item 31 key (1919805647 INODE_REF 1919785864) itemoff 14389 itemsize 26
>         item 32 key (1919805647 EXTENT_DATA 0) itemoff 14336 itemsize 53
> (...)
> 
> I'll post tomorrow if I get more overnight
> 
> 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
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
"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

Re: btrfs check: add_missing_dir_index: BUG_ON `ret` triggered, value -17

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 5541 bytes --]



On 2017年11月17日 15:30, Marc MERLIN wrote:
> Here's the whole output:
> gargamel:~# btrfs-debug-tree -t 258 /dev/mapper/raid0d1 | grep 1919805647

Sorry, I missed "-C10" parameter for grep.

>                 location key (1919805647 INODE_ITEM 0) type FILE

This should be the DIR_ITEM/DIR_INDEX pointing to that inode.

Although there is only one hit, means we missed one DIR_ITEM/DIR_INDEX.
Maybe it's btrfs-progs re-inserting the wrong DIR_INDEX/DIR_ITEM that
leads to -EEXIST.

This needs extra info from "-C10" to determine.

>         item 30 key (1919805647 INODE_ITEM 0) itemoff 14415 itemsize 160
>         item 31 key (1919805647 INODE_REF 1919785864) itemoff 14389 itemsize 26

Here we know the parent inode number is 1919785864.

>         item 32 key (1919805647 EXTENT_DATA 0) itemoff 14336 itemsize 53
> parent transid verify failed on 1173964603392 wanted 2244945 found 2247404
> parent transid verify failed on 1173964603392 wanted 2244945 found 2247404
> parent transid verify failed on 1173964603392 wanted 2244945 found 2247404
> parent transid verify failed on 1173964603392 wanted 2244945 found 2247404
> Ignoring transid failure

I think the transid failure is the root cause.

Although what we could try is to avoid BUG_ON(), but I'm afraid the
problem is more severe than my expectation.

Any idea how such corruption happened?

Thanks,
Qu

> parent transid verify failed on 1652248100864 wanted 2245186 found 2247494
> parent transid verify failed on 1652248100864 wanted 2245186 found 2247494
> parent transid verify failed on 1652248100864 wanted 2245186 found 2247494
> parent transid verify failed on 1652248100864 wanted 2245186 found 2247494
> Ignoring transid failure
> parent transid verify failed on 1174605512704 wanted 2245171 found 2247435
> parent transid verify failed on 1174605512704 wanted 2245171 found 2247435
> parent transid verify failed on 1174605512704 wanted 2245171 found 2247435
> parent transid verify failed on 1174605512704 wanted 2245171 found 2247435
> Ignoring transid failure
> WARNING: eb corrupted: item 130 eb level 0 next level 2, skipping the rest
> 
> 
> On Thu, Nov 16, 2017 at 10:17:07PM -0800, Marc MERLIN wrote:
>> On Fri, Nov 17, 2017 at 01:17:19PM +0800, Qu Wenruo wrote:
>>>
>>>
>>> On 2017年11月17日 10:26, Marc MERLIN wrote:
>>>> Howdy,
>>>>
>>>> Up to date git pull from btrfs-progs:
>>>>
>>>> gargamel:~# btrfs check --repair /dev/mapper/raid0d1
>>>> enabling repair mode
>>>> Checking filesystem on /dev/mapper/raid0d1
>>>> UUID: 01334b81-c0db-4e80-92e4-cac4da867651
>>>> checking extents
>>>> corrupt extent record: key 203003699200 168 40960
>>>> corrupt extent record: key 203003764736 168 172032
>>>> ref mismatch on [203003699200 40960] extent item 0, found 1
>>>> Data backref 203003699200 root 258 owner 1933897829 offset 0 num_refs 0 not found in extent tree
>>>> Incorrect local backref count on 203003699200 root 258 owner 1933897829 offset 0 found 1 wanted 0 back 0x5596988c2130
>>>> backpointer mismatch on [203003699200 40960]
>>>> repair deleting extent record: key 203003699200 168 40960
>>>> adding new data backref on 203003699200 root 258 owner 1933897829 offset 0 found 1
>>>> Repaired extent references for 203003699200
>>>> Data backref 203003764736 root 258 owner 1932315368 offset 0 num_refs 0 not found in extent tree
>>>> Incorrect local backref count on 203003764736 root 258 owner 1932315368 offset 0 found 1 wanted 0 back 0x5596dde358f0
>>>> backpointer mismatch on [203003764736 172032]
>>>> repair deleting extent record: key 203003764736 168 172032
>>>> adding new data backref on 203003764736 root 258 owner 1932315368 offset 0 found 1
>>>> Repaired extent references for 203003764736
>>>> Fixed 0 roots.
>>>> checking free space cache
>>>> cache and super generation don't match, space cache will be invalidated
>>>> checking fs roots
>>>> invalid location in dir item 0
>>>> Deleting bad dir index [1919785864,96,1958] root 258
>>>> Deleting bad dir index [1919785864,96,1957] root 258
>>>> repairing missing dir index item for inode 1919805647
>>>> cmds-check.c:2614: add_missing_dir_index: BUG_ON `ret` triggered, value -17
>>>
>>> -EEXIST. Btrfs check --repair is trying to re-insert some key which
>>> exists already.
>>>
>>> Would you please provide the output of "btrfs-debug-tree -t 258 | grep
>>> 1919805647" to help the debugging?
>>  
>> Sure. It may run all night and I'm going to bed now, but the output I
>> got so far, is:
>> gargamel:~# btrfs-debug-tree -t 258 /dev/mapper/raid0d1 | grep 1919805647
>>                 location key (1919805647 INODE_ITEM 0) type FILE
>>         item 30 key (1919805647 INODE_ITEM 0) itemoff 14415 itemsize 160
>>         item 31 key (1919805647 INODE_REF 1919785864) itemoff 14389 itemsize 26
>>         item 32 key (1919805647 EXTENT_DATA 0) itemoff 14336 itemsize 53
>> (...)
>>
>> I'll post tomorrow if I get more overnight
>>
>> 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
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 520 bytes --]

Re: btrfs check: add_missing_dir_index: BUG_ON `ret` triggered, value -17

[Marc MERLIN]

On Fri, Nov 17, 2017 at 04:12:07PM +0800, Qu Wenruo wrote:
> 
> 
> On 2017年11月17日 15:30, Marc MERLIN wrote:
> > Here's the whole output:
> > gargamel:~# btrfs-debug-tree -t 258 /dev/mapper/raid0d1 | grep 1919805647
> 
> Sorry, I missed "-C10" parameter for grep.
 
                generation 2231977 transid 2237084 size 64 nbytes 0
                block group 0 mode 40755 links 1 uid 33 gid 33 rdev 0
                sequence 0 flags 0x1710(none)
                atime 1510290002.516060162 (2017-11-09 21:00:02)
                ctime 1510477350.88506455 (2017-11-12 01:02:30)
                mtime 1510477350.88506455 (2017-11-12 01:02:30)
                otime 1510290002.516060162 (2017-11-09 21:00:02)
        item 26 key (1919785864 INODE_REF 1919785862) itemoff 14683 itemsize 12
                index 2 namelen 2 name: 00
        item 27 key (1919785864 DIR_ITEM 2591417872) itemoff 14637 itemsize 46
                location key (1919805647 INODE_ITEM 0) type FILE
                transid 2231988 data_len 0 name_len 16
                name: 1955-capture.jpg
        item 28 key (1919785864 DIR_ITEM 3406016191) itemoff 14591 itemsize 46
                location key (1919805657 INODE_ITEM 0) type FILE
                transid 2231988 data_len 0 name_len 16
                name: 1956-capture.jpg
        item 29 key (1919785864 DIR_INDEX 1957) itemoff 14575 itemsize 16
                location key (7383370114097217536 UNKNOWN.211 15651972432879681580) type DIR_ITEM.0
                transid 72057594045427176 data_len 0 name_len 0
                name: 
        item 30 key (1919805647 INODE_ITEM 0) itemoff 14415 itemsize 160
                generation 2231988 transid 2231989 size 81701 nbytes 81920
                block group 0 mode 100644 links 1 uid 33 gid 33 rdev 0
                sequence 8 flags 0x14(NOCOMPRESS)
                atime 1510290392.703320623 (2017-11-09 21:06:32)
                ctime 1510290392.715320477 (2017-11-09 21:06:32)
                mtime 1510290392.715320477 (2017-11-09 21:06:32)
                otime 1510290392.703320623 (2017-11-09 21:06:32)
        item 31 key (1919805647 INODE_REF 1919785864) itemoff 14389 itemsize 26
                index 1957 namelen 16 name: 1955-capture.jpg
        item 32 key (1919805647 EXTENT_DATA 0) itemoff 14336 itemsize 53
                generation 2231989 type 1 (regular)
                extent data disk byte 2381649588224 nr 81920
                extent data offset 0 nr 81920 ram 81920
                extent compression 0 (none)
        item 33 key (1919805657 INODE_ITEM 0) itemoff 14176 itemsize 160
                generation 2231988 transid 2231989 size 81856 nbytes 81920
                block group 0 mode 100644 links 1 uid 33 gid 33 rdev 0
                sequence 8 flags 0x14(NOCOMPRESS)
                atime 1510290392.919317997 (2017-11-09 21:06:32)
                ctime 1510290392.931317852 (2017-11-09 21:06:32)


> Although what we could try is to avoid BUG_ON(), but I'm afraid the
> problem is more severe than my expectation.
 
How does it look now?

> Any idea how such corruption happened?

Sigh, I wish I knew.

It feels like every btrfs filesystem I've had between my 3 systems has
gotten inexplicably corrupted at least once.
This one is not even using bcache, just dmcrypt underneath.

It's my only one using btrfs raid (1):
gargamel:~# btrfs fi show /dev/mapper/raid0d1 
Label: 'btrfs_space'  uuid: 01334b81-c0db-4e80-92e4-cac4da867651
        Total devices 2 FS bytes used 1.12TiB
        devid    1 size 836.13GiB used 722.03GiB path /dev/mapper/raid0d1
        devid    2 size 836.13GiB used 722.03GiB path /dev/mapper/raid0d2

Data, RAID0: total=1.38TiB, used=1.11TiB
System, RAID1: total=32.00MiB, used=128.00KiB
Metadata, RAID1: total=13.00GiB, used=8.54GiB
GlobalReserve, single: total=512.00MiB, used=0.00B

Now, I didn't get errors or warnings, or even scrub warnings on it, I just ran 
btrfs check to see what would happen.

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

Re: btrfs check: add_missing_dir_index: BUG_ON `ret` triggered, value -17

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 4555 bytes --]



On 2017年11月17日 23:50, Marc MERLIN wrote:
> On Fri, Nov 17, 2017 at 04:12:07PM +0800, Qu Wenruo wrote:
>>
>>
>> On 2017年11月17日 15:30, Marc MERLIN wrote:
>>> Here's the whole output:
>>> gargamel:~# btrfs-debug-tree -t 258 /dev/mapper/raid0d1 | grep 1919805647
>>
>> Sorry, I missed "-C10" parameter for grep.
>  
>                 generation 2231977 transid 2237084 size 64 nbytes 0
>                 block group 0 mode 40755 links 1 uid 33 gid 33 rdev 0
>                 sequence 0 flags 0x1710(none)
>                 atime 1510290002.516060162 (2017-11-09 21:00:02)
>                 ctime 1510477350.88506455 (2017-11-12 01:02:30)
>                 mtime 1510477350.88506455 (2017-11-12 01:02:30)
>                 otime 1510290002.516060162 (2017-11-09 21:00:02)
>         item 26 key (1919785864 INODE_REF 1919785862) itemoff 14683 itemsize 12
>                 index 2 namelen 2 name: 00
>         item 27 key (1919785864 DIR_ITEM 2591417872) itemoff 14637 itemsize 46
>                 location key (1919805647 INODE_ITEM 0) type FILE
>                 transid 2231988 data_len 0 name_len 16
>                 name: 1955-capture.jpg

OK, this DIR_ITEM matches with INODE_REF.
So btrfs-check should only need to insert DIR_INDEX for it.

>         item 28 key (1919785864 DIR_ITEM 3406016191) itemoff 14591 itemsize 46
>                 location key (1919805657 INODE_ITEM 0) type FILE
>                 transid 2231988 data_len 0 name_len 16
>                 name: 1956-capture.jpg
>         item 29 key (1919785864 DIR_INDEX 1957) itemoff 14575 itemsize 16
>                 location key (7383370114097217536 UNKNOWN.211 15651972432879681580) type DIR_ITEM.0
>                 transid 72057594045427176 data_len 0 name_len 0
>                 name: 
>         item 30 key (1919805647 INODE_ITEM 0) itemoff 14415 itemsize 160
>                 generation 2231988 transid 2231989 size 81701 nbytes 81920
>                 block group 0 mode 100644 links 1 uid 33 gid 33 rdev 0
>                 sequence 8 flags 0x14(NOCOMPRESS)
>                 atime 1510290392.703320623 (2017-11-09 21:06:32)
>                 ctime 1510290392.715320477 (2017-11-09 21:06:32)
>                 mtime 1510290392.715320477 (2017-11-09 21:06:32)
>                 otime 1510290392.703320623 (2017-11-09 21:06:32)
>         item 31 key (1919805647 INODE_REF 1919785864) itemoff 14389 itemsize 26
>                 index 1957 namelen 16 name: 1955-capture.jpg
>         item 32 key (1919805647 EXTENT_DATA 0) itemoff 14336 itemsize 53
>                 generation 2231989 type 1 (regular)
>                 extent data disk byte 2381649588224 nr 81920
>                 extent data offset 0 nr 81920 ram 81920
>                 extent compression 0 (none)
>         item 33 key (1919805657 INODE_ITEM 0) itemoff 14176 itemsize 160
>                 generation 2231988 transid 2231989 size 81856 nbytes 81920
>                 block group 0 mode 100644 links 1 uid 33 gid 33 rdev 0
>                 sequence 8 flags 0x14(NOCOMPRESS)
>                 atime 1510290392.919317997 (2017-11-09 21:06:32)
>                 ctime 1510290392.931317852 (2017-11-09 21:06:32)

No extra interesting things here.

> 
> 
>> Although what we could try is to avoid BUG_ON(), but I'm afraid the
>> problem is more severe than my expectation.
>  
> How does it look now?

At least we know what btrfs check should do.
I could dig it a little deeper to see if we could fix it.
(Or something strange happened again)

Thanks
Qu

> 
>> Any idea how such corruption happened?
> 
> Sigh, I wish I knew.
> 
> It feels like every btrfs filesystem I've had between my 3 systems has
> gotten inexplicably corrupted at least once.
> This one is not even using bcache, just dmcrypt underneath.
> 
> It's my only one using btrfs raid (1):
> gargamel:~# btrfs fi show /dev/mapper/raid0d1 
> Label: 'btrfs_space'  uuid: 01334b81-c0db-4e80-92e4-cac4da867651
>         Total devices 2 FS bytes used 1.12TiB
>         devid    1 size 836.13GiB used 722.03GiB path /dev/mapper/raid0d1
>         devid    2 size 836.13GiB used 722.03GiB path /dev/mapper/raid0d2
> 
> Data, RAID0: total=38TiB, used=1.11TiB
> System, RAID1: total2.00MiB, used\x128.00KiB
> Metadata, RAID1: total\x13.00GiB, used=8.54GiB
> GlobalReserve, single: totalQ2.00MiB, used=0.00B
> 
> Now, I didn't get errors or warnings, or even scrub warnings on it, I just ran 
> btrfs check to see what would happen.
> 
> Marc
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 520 bytes --]

Re: btrfs check: add_missing_dir_index: BUG_ON `ret` triggered, value -17

[Marc MERLIN]

On Sat, Nov 18, 2017 at 08:16:32AM +0800, Qu Wenruo wrote:
> >         item 27 key (1919785864 DIR_ITEM 2591417872) itemoff 14637 itemsize 46
> >                 location key (1919805647 INODE_ITEM 0) type FILE
> >                 transid 2231988 data_len 0 name_len 16
> >                 name: 1955-capture.jpg
> 
> OK, this DIR_ITEM matches with INODE_REF.
> So btrfs-check should only need to insert DIR_INDEX for it.
> > 
> >> Although what we could try is to avoid BUG_ON(), but I'm afraid the
> >> problem is more severe than my expectation.
> >  
> > How does it look now?
> 
> At least we know what btrfs check should do.
> I could dig it a little deeper to see if we could fix it.
> (Or something strange happened again)

Thanks for having had a look, hopefully it helps improving btrfs check,
thanks for getting the info and getting it turned into better code :)

In the meantime this was an easy FS to just wipe and start over with, so
I just did that.

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