Re: btrfs check: add_missing_dir_index: BUG_ON `ret` triggered, value -17
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 -- 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: btrfs check: add_missing_dir_index: BUG_ON `ret` triggered, value -17
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 > devid1 size 836.13GiB used 722.03GiB path /dev/mapper/raid0d1 > devid2 size 836.13GiB used 722.03GiB path /dev/mapper/raid0d2 > > Data, RAID0: total=38TiB, used=1.11TiB > System, RAID1: total2.00MiB, used8.00KiB > Metadata, RAID1: total.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 > signature.asc Description: OpenPGP digital signature
Re: btrfs check: add_missing_dir_index: BUG_ON `ret` triggered, value -17
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 devid1 size 836.13GiB used 722.03GiB path /dev/mapper/raid0d1 devid2 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 -- 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: btrfs check: add_missing_dir_index: BUG_ON `ret` triggered, value -17
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
Re: btrfs check: add_missing_dir_index: BUG_ON `ret` triggered, value -17
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 majord...@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
Re: btrfs check: add_missing_dir_index: BUG_ON `ret` triggered, value -17
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs check: add_missing_dir_index: BUG_ON `ret` triggered, value -17
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 > signature.asc Description: OpenPGP digital signature
btrfs check: add_missing_dir_index: BUG_ON `ret` triggered, value -17
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/ -- 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
