invalid files names, btrfs check can't repair it

invalid files names, btrfs check can't repair it

[Sebastian Andrzej Siewior]

Hi,

so I had bad memory and before I realized it and removed it btrfs took some
damage. Now I have this:

|ls -lh crap/
|ls: cannot access 'crap/2f3f379b2a3d7499471edb74869efe-1948311.d': No such file or directory
|ls: cannot access 'crap/454bf066ddfbf42e0f3b77ea71c82f-878732.o': No such file or directory
|total 0
|-????????? ? ? ? ?            ? 2f3f379b2a3d7499471edb74869efe-1948311.d
|-????????? ? ? ? ?            ? 454bf066ddfbf42e0f3b77ea71c82f-878732.o

and in dmesg I see:

| BTRFS critical (device sda4): invalid dir item type: 33
| BTRFS critical (device sda4): invalid dir item name len: 8231

`btrfs check' (from v4.14.1) finds them and prints them but has no idea
what to do with it. Would it be possible to let the check tool rename
the offended filename to something (like its inode number) put it in
lost+found if it has any data attached to it and otherwise simply remove
it? Right now I can't remove that folder.

Sebastian

Re: invalid files names, btrfs check can't repair it

[Timofey Titovets]

2018-01-13 0:04 GMT+03:00 Sebastian Andrzej Siewior <sebastian@breakpoint.cc>:
> Hi,
>
> so I had bad memory and before I realized it and removed it btrfs took some
> damage. Now I have this:
>
> |ls -lh crap/
> |ls: cannot access 'crap/2f3f379b2a3d7499471edb74869efe-1948311.d': No such file or directory
> |ls: cannot access 'crap/454bf066ddfbf42e0f3b77ea71c82f-878732.o': No such file or directory
> |total 0
> |-????????? ? ? ? ?            ? 2f3f379b2a3d7499471edb74869efe-1948311.d
> |-????????? ? ? ? ?            ? 454bf066ddfbf42e0f3b77ea71c82f-878732.o
>
> and in dmesg I see:
>
> | BTRFS critical (device sda4): invalid dir item type: 33
> | BTRFS critical (device sda4): invalid dir item name len: 8231
>
> `btrfs check' (from v4.14.1) finds them and prints them but has no idea
> what to do with it. Would it be possible to let the check tool rename
> the offended filename to something (like its inode number) put it in
> lost+found if it has any data attached to it and otherwise simply remove
> it? Right now I can't remove that folder.
>
> Sebastian
> --
> 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

Deletion:
If that happens in subvol, you can create new subvol, reflink data and
delete old vol.
I don't know other ways to fix that entries.

P.S.
I have that issue without bad ram, but by some system hangs/resets
(I've use notreelog
 as workaround for now).

Thanks.
-- 
Have a nice day,
Timofey.

Re: invalid files names, btrfs check can't repair it

[Qu Wenruo]

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



On 2018年01月13日 05:04, Sebastian Andrzej Siewior wrote:
> Hi,
> 
> so I had bad memory and before I realized it and removed it btrfs took some
> damage. Now I have this:
> 
> |ls -lh crap/
> |ls: cannot access 'crap/2f3f379b2a3d7499471edb74869efe-1948311.d': No such file or directory
> |ls: cannot access 'crap/454bf066ddfbf42e0f3b77ea71c82f-878732.o': No such file or directory
> |total 0
> |-????????? ? ? ? ?            ? 2f3f379b2a3d7499471edb74869efe-1948311.d
> |-????????? ? ? ? ?            ? 454bf066ddfbf42e0f3b77ea71c82f-878732.o
> 
> and in dmesg I see:
> 
> | BTRFS critical (device sda4): invalid dir item type: 33
> | BTRFS critical (device sda4): invalid dir item name len: 8231
> 
> `btrfs check' (from v4.14.1) finds them and prints them but has no idea
> what to do with it. Would it be possible to let the check tool rename
> the offended filename to something (like its inode number) put it in
> lost+found if it has any data attached to it and otherwise simply remove
> it? Right now I can't remove that folder.

'Btrfs check' output please.

And in fact, btrfs check --repair has the ability to move/re-link such
file and keeps its content, as long as there is any info found in
DIR_INDEX/DIR_ITEM/INODE_REF.

If repair can't handle it, the output could help us to craft such case
and enhance btrfs-progs to repair it.

Thanks,
Qu

> 
> Sebastian
> --
> 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: invalid files names, btrfs check can't repair it

[Sebastian Andrzej Siewior]

On 2018-01-13 08:56:24 [+0800], Qu Wenruo wrote:
> 'Btrfs check' output please.

~# btrfs check --repair -p /dev/sdb4
enabling repair mode
Checking filesystem on /dev/sdb4
UUID: b3bfb56e-d445-4335-93f0-c1fb2d1f6df1
Fixed 0 roots.
checking extents [o]
No device size related problem found
cache and super generation don't match, space cache will be invalidated
checkingunresolved ref dir 57648595 index 435 namelen 40 name 2f3f379b2a3d7499471edb74869efe-1948311.d filetype 1 errors 80, filetype mismatch
        unresolved ref dir 57648595 index 1137 namelen 39 name 454bf066ddfbf42e0f3b77ea71c82f-878732.o filetype 1 errors 100, name too long

checking csums
checking root refs
found 63691468800 bytes used, no error found
total csum bytes: 61339388
total tree bytes: 860536832
total fs tree bytes: 688816128
total extent tree bytes: 84545536
btree space waste bytes: 224424238
file data blocks allocated: 62890745856
 referenced 62829219840
~# 

> And in fact, btrfs check --repair has the ability to move/re-link such
> file and keeps its content, as long as there is any info found in
> DIR_INDEX/DIR_ITEM/INODE_REF.
> 
> If repair can't handle it, the output could help us to craft such case
> and enhance btrfs-progs to repair it.

Is the output enough or do you want me to do more?

> Thanks,
> Qu

Sebastian

Re: invalid files names, btrfs check can't repair it

[Qu Wenruo]

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



On 2018年01月14日 04:41, Sebastian Andrzej Siewior wrote:
> On 2018-01-13 08:56:24 [+0800], Qu Wenruo wrote:
>> 'Btrfs check' output please.
> 
> ~# btrfs check --repair -p /dev/sdb4
> enabling repair mode
> Checking filesystem on /dev/sdb4
> UUID: b3bfb56e-d445-4335-93f0-c1fb2d1f6df1
> Fixed 0 roots.
> checking extents [o]
> No device size related problem found
> cache and super generation don't match, space cache will be invalidated
> checkingunresolved ref dir 57648595 index 435 namelen 40 name 2f3f379b2a3d7499471edb74869efe-1948311.d filetype 1 errors 80, filetype mismatch
>         unresolved ref dir 57648595 index 1137 namelen 39 name 454bf066ddfbf42e0f3b77ea71c82f-878732.o filetype 1 errors 100, name too long

Now we know the affected dir (ino 57648595).
> 
> checking csums
> checking root refs
> found 63691468800 bytes used, no error found
> total csum bytes: 61339388
> total tree bytes: 860536832
> total fs tree bytes: 688816128
> total extent tree bytes: 84545536
> btree space waste bytes: 224424238
> file data blocks allocated: 62890745856
>  referenced 62829219840
> ~# 
> 
>> And in fact, btrfs check --repair has the ability to move/re-link such
>> file and keeps its content, as long as there is any info found in
>> DIR_INDEX/DIR_ITEM/INODE_REF.
>>
>> If repair can't handle it, the output could help us to craft such case
>> and enhance btrfs-progs to repair it.
> 
> Is the output enough or do you want me to do more?

Still needs more. (and maybe even more depending on the output)

The original mode doesn't report error clear enough, so it would help if
--mode=lowmem can be used.

# btrfs check --mode=lowmem /dev/sdb4

And the tree dump of the affected dir inode would help too:

# btrfs inspect dump-tree /dev/sdb4 | grep -C 20 \(57648595

Thanks,
Qu

> 
>> Thanks,
>> Qu
> 
> Sebastian
> --
> 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: invalid files names, btrfs check can't repair it

[Sebastian Andrzej Siewior]

On 2018-01-14 08:36:41 [+0800], Qu Wenruo wrote:
> Still needs more. (and maybe even more depending on the output)
> 
> The original mode doesn't report error clear enough, so it would help if
> --mode=lowmem can be used.
> 
> # btrfs check --mode=lowmem /dev/sdb4

~# btrfs check --mode=lowmem /dev/sdb4
Checking filesystem on /dev/sdb4
UUID: b3bfb56e-d445-4335-93f0-c1fb2d1f6df1
checking extents
checking free space cache
Wanted bytes 4096, found 8192 for off 159178047488
Wanted bytes 1073725440, found 8192 for off 159178047488
cache appears valid but isn't 159178031104
ERROR: errors found in free space cache
found 63691210752 bytes used, error(s) found
total csum bytes: 61339388
total tree bytes: 860540928
total fs tree bytes: 688816128
total extent tree bytes: 84549632
btree space waste bytes: 224428280
file data blocks allocated: 62890483712
 referenced 62828957696

> And the tree dump of the affected dir inode would help too:
> 
> # btrfs inspect dump-tree /dev/sdb4 | grep -C 20 \(57648595

~# btrfs inspect dump-tree /dev/sdb4 | grep -C 20 \(57648595
                generation 88831 type 1 (regular)
                extent data disk byte 193705541632 nr 134217728
                extent data offset 0 nr 134217728 ram 134217728
                extent compression 0 (none)
        item 4 key (57022249 EXTENT_DATA 402653184) itemoff 3769 itemsize 53
                generation 88831 type 1 (regular)
                extent data disk byte 190035439616 nr 60600320
                extent data offset 0 nr 60600320 ram 60600320
                extent compression 0 (none)
        item 5 key (57643659 INODE_ITEM 0) itemoff 3609 itemsize 160
                generation 89044 transid 89423 size 2 nbytes 0
                block group 0 mode 40755 links 1 uid 1000 gid 1000 rdev 0
                sequence 0 flags 0x150be(none)
                atime 1513266994.264310920 (2017-12-14 16:56:34)
                ctime 1513868332.369178014 (2017-12-21 15:58:52)
                mtime 1513868332.369178014 (2017-12-21 15:58:52)
                otime 1513266994.264310920 (2017-12-14 16:56:34)
        item 6 key (57643659 INODE_REF 58477961) itemoff 3598 itemsize 11
                index 6 namelen 1 name: 4
        item 7 key (57643659 DIR_ITEM 4189400016) itemoff 3567 itemsize 31
                location key (57648595 INODE_ITEM 0) type DIR
                transid 89045 data_len 0 name_len 1
                name: d
        item 8 key (57643659 DIR_INDEX 113) itemoff 3536 itemsize 31
                location key (57648595 INODE_ITEM 0) type DIR
                transid 89045 data_len 0 name_len 1
                name: d
        item 9 key (57643872 INODE_ITEM 0) itemoff 3376 itemsize 160
                generation 89044 transid 89699 size 0 nbytes 0
                block group 0 mode 40755 links 1 uid 1000 gid 1000 rdev 0
                sequence 0 flags 0x603b3(none)
                atime 1513266995.540343055 (2017-12-14 16:56:35)
                ctime 1515602448.66422211 (2018-01-10 17:40:48)
                mtime 1515602448.66422211 (2018-01-10 17:40:48)
                otime 1513266995.540343055 (2017-12-14 16:56:35)
        item 10 key (57643872 INODE_REF 682) itemoff 3363 itemsize 13
                index 58 namelen 3 name: tmp
        item 11 key (57648595 INODE_ITEM 0) itemoff 3203 itemsize 160
                generation 89045 transid 89423 size 8350 nbytes 0
                block group 0 mode 40755 links 1 uid 1000 gid 1000 rdev 0
                sequence 0 flags 0xc90(none)
                atime 1513267009.164686143 (2017-12-14 16:56:49)
                ctime 1513868329.753150507 (2017-12-21 15:58:49)
                mtime 1513868329.753150507 (2017-12-21 15:58:49)
                otime 1513267009.164686143 (2017-12-14 16:56:49)
        item 12 key (57648595 INODE_REF 57643659) itemoff 3192 itemsize 11
                index 113 namelen 1 name: d
        item 13 key (57648595 DIR_ITEM 3331247447) itemoff 3123 itemsize 69
                location key (58472210 INODE_ITEM 0) type FILE
                transid 89418 data_len 0 name_len 8231
                name: 454bf066ddfbf42e0f3b77ea71c82f-878732.oq
        item 14 key (57648595 DIR_ITEM 3363354030) itemoff 3053 itemsize 70
                location key (57923894 INODE_ITEM 0) type DIR_ITEM.33
                transid 89142 data_len 0 name_len 40
                name: 2f3f379b2a3d7499471edb74869efe-1948311.d
        item 15 key (57648595 DIR_INDEX 435) itemoff 2983 itemsize 70
                location key (57923894 INODE_ITEM 0) type FILE
                transid 89142 data_len 0 name_len 40
                name: 2f3f379b2a3d7499471edb74869efe-1948311.d
        item 16 key (57648595 DIR_INDEX 1137) itemoff 2914 itemsize 69
                location key (58472210 INODE_ITEM 0) type FILE
                transid 89418 data_len 0 name_len 39
                name: 454bf066ddfbf42e0f3b77ea71c82f-878732.o
        item 17 key (57923894 INODE_ITEM 0) itemoff 2754 itemsize 160
                generation 89142 transid 89142 size 36092 nbytes 36864
                block group 0 mode 100644 links 1 uid 1000 gid 1000 rdev 0
                sequence 0 flags 0x91(none)
                atime 1513278413.460486168 (2017-12-14 20:06:53)
                ctime 1513278413.460486168 (2017-12-14 20:06:53)
                mtime 1513278413.460486168 (2017-12-14 20:06:53)
                otime 1513278413.460486168 (2017-12-14 20:06:53)
        item 18 key (57923894 INODE_REF 57648595) itemoff 2704 itemsize 50
                index 435 namelen 40 name: 2f3f379b2a3d7499471edb74869efe-1948311.d
        item 19 key (57923894 EXTENT_DATA 0) itemoff 2651 itemsize 53
                generation 89142 type 1 (regular)
                extent data disk byte 123290755072 nr 36864
                extent data offset 0 nr 36864 ram 36864
                extent compression 0 (none)
        item 20 key (58191388 INODE_ITEM 0) itemoff 2491 itemsize 160
                generation 89259 transid 89259 size 395280 nbytes 397312
> Thanks,
> Qu

Sebastian

Re: invalid files names, btrfs check can't repair it

[Qu Wenruo]

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



On 2018年01月15日 00:38, Sebastian Andrzej Siewior wrote:
> On 2018-01-14 08:36:41 [+0800], Qu Wenruo wrote:
>> Still needs more. (and maybe even more depending on the output)
>>
>> The original mode doesn't report error clear enough, so it would help if
>> --mode=lowmem can be used.
>>
>> # btrfs check --mode=lowmem /dev/sdb4
> 
> ~# btrfs check --mode=lowmem /dev/sdb4
> Checking filesystem on /dev/sdb4
> UUID: b3bfb56e-d445-4335-93f0-c1fb2d1f6df1
> checking extents
> checking free space cache
> Wanted bytes 4096, found 8192 for off 159178047488
> Wanted bytes 1073725440, found 8192 for off 159178047488
> cache appears valid but isn't 159178031104
> ERROR: errors found in free space cache

A new bug is exposed for lowmem mode.
It doesn't check fs tree if space cache has any problem.

> found 63691210752 bytes used, error(s) found
> total csum bytes: 61339388
> total tree bytes: 860540928
> total fs tree bytes: 688816128
> total extent tree bytes: 84549632
> btree space waste bytes: 224428280
> file data blocks allocated: 62890483712
>  referenced 62828957696
> 
>> And the tree dump of the affected dir inode would help too:
>>
>> # btrfs inspect dump-tree /dev/sdb4 | grep -C 20 \(57648595
> 
> ~# btrfs inspect dump-tree /dev/sdb4 | grep -C 20 \(57648595
>                 generation 88831 type 1 (regular)
>                 extent data disk byte 193705541632 nr 134217728
>                 extent data offset 0 nr 134217728 ram 134217728
>                 extent compression 0 (none)
>         item 4 key (57022249 EXTENT_DATA 402653184) itemoff 3769 itemsize 53
>                 generation 88831 type 1 (regular)
>                 extent data disk byte 190035439616 nr 60600320
>                 extent data offset 0 nr 60600320 ram 60600320
>                 extent compression 0 (none)
>         item 5 key (57643659 INODE_ITEM 0) itemoff 3609 itemsize 160
>                 generation 89044 transid 89423 size 2 nbytes 0
>                 block group 0 mode 40755 links 1 uid 1000 gid 1000 rdev 0
>                 sequence 0 flags 0x150be(none)
>                 atime 1513266994.264310920 (2017-12-14 16:56:34)
>                 ctime 1513868332.369178014 (2017-12-21 15:58:52)
>                 mtime 1513868332.369178014 (2017-12-21 15:58:52)
>                 otime 1513266994.264310920 (2017-12-14 16:56:34)
>         item 6 key (57643659 INODE_REF 58477961) itemoff 3598 itemsize 11
>                 index 6 namelen 1 name: 4
>         item 7 key (57643659 DIR_ITEM 4189400016) itemoff 3567 itemsize 31
>                 location key (57648595 INODE_ITEM 0) type DIR
>                 transid 89045 data_len 0 name_len 1
>                 name: d
>         item 8 key (57643659 DIR_INDEX 113) itemoff 3536 itemsize 31
>                 location key (57648595 INODE_ITEM 0) type DIR
>                 transid 89045 data_len 0 name_len 1
>                 name: d
>         item 9 key (57643872 INODE_ITEM 0) itemoff 3376 itemsize 160
>                 generation 89044 transid 89699 size 0 nbytes 0
>                 block group 0 mode 40755 links 1 uid 1000 gid 1000 rdev 0
>                 sequence 0 flags 0x603b3(none)
>                 atime 1513266995.540343055 (2017-12-14 16:56:35)
>                 ctime 1515602448.66422211 (2018-01-10 17:40:48)
>                 mtime 1515602448.66422211 (2018-01-10 17:40:48)
>                 otime 1513266995.540343055 (2017-12-14 16:56:35)
>         item 10 key (57643872 INODE_REF 682) itemoff 3363 itemsize 13
>                 index 58 namelen 3 name: tmp
>         item 11 key (57648595 INODE_ITEM 0) itemoff 3203 itemsize 160
>                 generation 89045 transid 89423 size 8350 nbytes 0
>                 block group 0 mode 40755 links 1 uid 1000 gid 1000 rdev 0
>                 sequence 0 flags 0xc90(none)
>                 atime 1513267009.164686143 (2017-12-14 16:56:49)
>                 ctime 1513868329.753150507 (2017-12-21 15:58:49)
>                 mtime 1513868329.753150507 (2017-12-21 15:58:49)
>                 otime 1513267009.164686143 (2017-12-14 16:56:49)
>         item 12 key (57648595 INODE_REF 57643659) itemoff 3192 itemsize 11
>                 index 113 namelen 1 name: d
>         item 13 key (57648595 DIR_ITEM 3331247447) itemoff 3123 itemsize 69
>                 location key (58472210 INODE_ITEM 0) type FILE
>                 transid 89418 data_len 0 name_len 8231
>                 name: 454bf066ddfbf42e0f3b77ea71c82f-878732.oq
>         item 14 key (57648595 DIR_ITEM 3363354030) itemoff 3053 itemsize 70
>                 location key (57923894 INODE_ITEM 0) type DIR_ITEM.33
>                 transid 89142 data_len 0 name_len 40
>                 name: 2f3f379b2a3d7499471edb74869efe-1948311.d
>         item 15 key (57648595 DIR_INDEX 435) itemoff 2983 itemsize 70
>                 location key (57923894 INODE_ITEM 0) type FILE

Please run the following command too:

# btrfs inspect dump-tree <device> | grep -C20 \(57923894

>                 transid 89142 data_len 0 name_len 40
>                 name: 2f3f379b2a3d7499471edb74869efe-1948311.d
>         item 16 key (57648595 DIR_INDEX 1137) itemoff 2914 itemsize 69
>                 location key (58472210 INODE_ITEM 0) type FILE

And this command too:

# btrfs inspect dump-tree <device> | grep -C20 \(58472210

Thanks,
Qu

>                 transid 89418 data_len 0 name_len 39
>                 name: 454bf066ddfbf42e0f3b77ea71c82f-878732.o
>         item 17 key (57923894 INODE_ITEM 0) itemoff 2754 itemsize 160
>                 generation 89142 transid 89142 size 36092 nbytes 36864
>                 block group 0 mode 100644 links 1 uid 1000 gid 1000 rdev 0
>                 sequence 0 flags 0x91(none)
>                 atime 1513278413.460486168 (2017-12-14 20:06:53)
>                 ctime 1513278413.460486168 (2017-12-14 20:06:53)
>                 mtime 1513278413.460486168 (2017-12-14 20:06:53)
>                 otime 1513278413.460486168 (2017-12-14 20:06:53)
>         item 18 key (57923894 INODE_REF 57648595) itemoff 2704 itemsize 50
>                 index 435 namelen 40 name: 2f3f379b2a3d7499471edb74869efe-1948311.d
>         item 19 key (57923894 EXTENT_DATA 0) itemoff 2651 itemsize 53
>                 generation 89142 type 1 (regular)
>                 extent data disk byte 123290755072 nr 36864
>                 extent data offset 0 nr 36864 ram 36864
>                 extent compression 0 (none)
>         item 20 key (58191388 INODE_ITEM 0) itemoff 2491 itemsize 160
>                 generation 89259 transid 89259 size 395280 nbytes 397312
>> Thanks,
>> Qu
> 
> Sebastian
> 


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

Re: invalid files names, btrfs check can't repair it

[Lu Fengqi]

On Mon, Jan 15, 2018 at 09:26:27AM +0800, Qu Wenruo wrote:
>
>
>On 2018年01月15日 00:38, Sebastian Andrzej Siewior wrote:
>> On 2018-01-14 08:36:41 [+0800], Qu Wenruo wrote:
>>> Still needs more. (and maybe even more depending on the output)
>>>
>>> The original mode doesn't report error clear enough, so it would help if
>>> --mode=lowmem can be used.
>>>
>>> # btrfs check --mode=lowmem /dev/sdb4
>> 
>> ~# btrfs check --mode=lowmem /dev/sdb4
>> Checking filesystem on /dev/sdb4
>> UUID: b3bfb56e-d445-4335-93f0-c1fb2d1f6df1
>> checking extents
>> checking free space cache
>> Wanted bytes 4096, found 8192 for off 159178047488
>> Wanted bytes 1073725440, found 8192 for off 159178047488
>> cache appears valid but isn't 159178031104
>> ERROR: errors found in free space cache
>
>A new bug is exposed for lowmem mode.
>It doesn't check fs tree if space cache has any problem.
>

Just a reminder, the problem is not only for lowmem mode.

        ret = check_space_cache(root);
        err |= !!ret;
        if (ret) {
                if (btrfs_fs_compat_ro(info, FREE_SPACE_TREE))
                        error("errors found in free space tree");
                else
                        error("errors found in free space cache");
                goto out;
                ^^^
        }

        /*
         * We used to have to have these hole extents in between our real
         * extents so if we don't have this flag set we need to make sure there
         * are no gaps in the file extents for inodes, otherwise we can just
         * ignore it when this happens.
         */
        no_holes = btrfs_fs_incompat(root->fs_info, NO_HOLES);
        ret = do_check_fs_roots(info, &root_cache);
              ^^^
        err |= !!ret;
        if (ret) {
                error("errors found in fs roots");
                goto out;
        }

-- 
Thanks,
Lu

>> found 63691210752 bytes used, error(s) found
>> total csum bytes: 61339388
>> total tree bytes: 860540928
>> total fs tree bytes: 688816128
>> total extent tree bytes: 84549632
>> btree space waste bytes: 224428280
>> file data blocks allocated: 62890483712
>>  referenced 62828957696
>> 

Re: invalid files names, btrfs check can't repair it

[Qu Wenruo]

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



On 2018年01月15日 09:59, Lu Fengqi wrote:
> On Mon, Jan 15, 2018 at 09:26:27AM +0800, Qu Wenruo wrote:
>>
>>
>> On 2018年01月15日 00:38, Sebastian Andrzej Siewior wrote:
>>> On 2018-01-14 08:36:41 [+0800], Qu Wenruo wrote:
>>>> Still needs more. (and maybe even more depending on the output)
>>>>
>>>> The original mode doesn't report error clear enough, so it would help if
>>>> --mode=lowmem can be used.
>>>>
>>>> # btrfs check --mode=lowmem /dev/sdb4
>>>
>>> ~# btrfs check --mode=lowmem /dev/sdb4
>>> Checking filesystem on /dev/sdb4
>>> UUID: b3bfb56e-d445-4335-93f0-c1fb2d1f6df1
>>> checking extents
>>> checking free space cache
>>> Wanted bytes 4096, found 8192 for off 159178047488
>>> Wanted bytes 1073725440, found 8192 for off 159178047488
>>> cache appears valid but isn't 159178031104
>>> ERROR: errors found in free space cache
>>
>> A new bug is exposed for lowmem mode.
>> It doesn't check fs tree if space cache has any problem.
>>
> 
> Just a reminder, the problem is not only for lowmem mode.

Right, I'll fix it soon.

And BTW what makes the the output different from the original one?

Sebastaian, did you do extra write or other operation to the fs after
previous btrfs check?

Thanks,
Qu

> 
>         ret = check_space_cache(root);
>         err |= !!ret;
>         if (ret) {
>                 if (btrfs_fs_compat_ro(info, FREE_SPACE_TREE))
>                         error("errors found in free space tree");
>                 else
>                         error("errors found in free space cache");
>                 goto out;
>                 ^^^
>         }
> 
>         /*
>          * We used to have to have these hole extents in between our real
>          * extents so if we don't have this flag set we need to make sure there
>          * are no gaps in the file extents for inodes, otherwise we can just
>          * ignore it when this happens.
>          */
>         no_holes = btrfs_fs_incompat(root->fs_info, NO_HOLES);
>         ret = do_check_fs_roots(info, &root_cache);
>               ^^^
>         err |= !!ret;
>         if (ret) {
>                 error("errors found in fs roots");
>                 goto out;
>         }
> 


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

Re: invalid files names, btrfs check can't repair it

[Sebastian Andrzej Siewior]

On 2018-01-15 09:26:27 [+0800], Qu Wenruo wrote:
> Please run the following command too:
> 
> # btrfs inspect dump-tree <device> | grep -C20 \(57923894

~# btrfs inspect dump-tree /dev/sdb4 | grep -C20 \(57923894
                ctime 1515602448.66422211 (2018-01-10 17:40:48)
                mtime 1515602448.66422211 (2018-01-10 17:40:48)
                otime 1513266995.540343055 (2017-12-14 16:56:35)
        item 10 key (57643872 INODE_REF 682) itemoff 3363 itemsize 13
                index 58 namelen 3 name: tmp
        item 11 key (57648595 INODE_ITEM 0) itemoff 3203 itemsize 160
                generation 89045 transid 89423 size 8350 nbytes 0
                block group 0 mode 40755 links 1 uid 1000 gid 1000 rdev 0
                sequence 0 flags 0xc90(none)
                atime 1513267009.164686143 (2017-12-14 16:56:49)
                ctime 1513868329.753150507 (2017-12-21 15:58:49)
                mtime 1513868329.753150507 (2017-12-21 15:58:49)
                otime 1513267009.164686143 (2017-12-14 16:56:49)
        item 12 key (57648595 INODE_REF 57643659) itemoff 3192 itemsize 11
                index 113 namelen 1 name: d
        item 13 key (57648595 DIR_ITEM 3331247447) itemoff 3123 itemsize 69
                location key (58472210 INODE_ITEM 0) type FILE
                transid 89418 data_len 0 name_len 8231
                name: 454bf066ddfbf42e0f3b77ea71c82f-878732.oq
        item 14 key (57648595 DIR_ITEM 3363354030) itemoff 3053 itemsize 70
                location key (57923894 INODE_ITEM 0) type DIR_ITEM.33
                transid 89142 data_len 0 name_len 40
                name: 2f3f379b2a3d7499471edb74869efe-1948311.d
        item 15 key (57648595 DIR_INDEX 435) itemoff 2983 itemsize 70
                location key (57923894 INODE_ITEM 0) type FILE
                transid 89142 data_len 0 name_len 40
                name: 2f3f379b2a3d7499471edb74869efe-1948311.d
        item 16 key (57648595 DIR_INDEX 1137) itemoff 2914 itemsize 69
                location key (58472210 INODE_ITEM 0) type FILE
                transid 89418 data_len 0 name_len 39
                name: 454bf066ddfbf42e0f3b77ea71c82f-878732.o
        item 17 key (57923894 INODE_ITEM 0) itemoff 2754 itemsize 160
                generation 89142 transid 89142 size 36092 nbytes 36864
                block group 0 mode 100644 links 1 uid 1000 gid 1000 rdev 0
                sequence 0 flags 0x91(none)
                atime 1513278413.460486168 (2017-12-14 20:06:53)
                ctime 1513278413.460486168 (2017-12-14 20:06:53)
                mtime 1513278413.460486168 (2017-12-14 20:06:53)
                otime 1513278413.460486168 (2017-12-14 20:06:53)
        item 18 key (57923894 INODE_REF 57648595) itemoff 2704 itemsize 50
                index 435 namelen 40 name: 2f3f379b2a3d7499471edb74869efe-1948311.d
        item 19 key (57923894 EXTENT_DATA 0) itemoff 2651 itemsize 53
                generation 89142 type 1 (regular)
                extent data disk byte 123290755072 nr 36864
                extent data offset 0 nr 36864 ram 36864
                extent compression 0 (none)
        item 20 key (58191388 INODE_ITEM 0) itemoff 2491 itemsize 160
                generation 89259 transid 89259 size 395280 nbytes 397312
                block group 0 mode 100644 links 1 uid 1000 gid 1000 rdev 0
                sequence 0 flags 0xa4(none)
                atime 1513332325.477020047 (2017-12-15 11:05:25)
                ctime 1513332325.477020047 (2017-12-15 11:05:25)
                mtime 1513332325.477020047 (2017-12-15 11:05:25)
                otime 1513332325.477020047 (2017-12-15 11:05:25)
        item 21 key (58191388 INODE_REF 40424284) itemoff 2470 itemsize 21
                index 1094 namelen 11 name: bzImage.tsc
leaf 146426621952 items 46 free space 11 generation 89680 owner 5
leaf 146426621952 flags 0x1(WRITTEN) backref revision 1
fs uuid b3bfb56e-d445-4335-93f0-c1fb2d1f6df1
chunk uuid 732d73c9-d037-4406-8dcb-dfa101bc5a9b
        item 0 key (58191388 EXTENT_DATA 0) itemoff 3942 itemsize 53
                generation 87303 type 1 (regular)

> >                 transid 89142 data_len 0 name_len 40
> >                 name: 2f3f379b2a3d7499471edb74869efe-1948311.d
> >         item 16 key (57648595 DIR_INDEX 1137) itemoff 2914 itemsize 69
> >                 location key (58472210 INODE_ITEM 0) type FILE
> 
> And this command too:
> 
> # btrfs inspect dump-tree <device> | grep -C20 \(58472210

~# btrfs inspect dump-tree /dev/sdb4 | grep -C20 \(58472210
                generation 89044 transid 89699 size 0 nbytes 0
                block group 0 mode 40755 links 1 uid 1000 gid 1000 rdev 0
                sequence 0 flags 0x603b3(none)
                atime 1513266995.540343055 (2017-12-14 16:56:35)
                ctime 1515602448.66422211 (2018-01-10 17:40:48)
                mtime 1515602448.66422211 (2018-01-10 17:40:48)
                otime 1513266995.540343055 (2017-12-14 16:56:35)
        item 10 key (57643872 INODE_REF 682) itemoff 3363 itemsize 13
                index 58 namelen 3 name: tmp
        item 11 key (57648595 INODE_ITEM 0) itemoff 3203 itemsize 160
                generation 89045 transid 89423 size 8350 nbytes 0
                block group 0 mode 40755 links 1 uid 1000 gid 1000 rdev 0
                sequence 0 flags 0xc90(none)
                atime 1513267009.164686143 (2017-12-14 16:56:49)
                ctime 1513868329.753150507 (2017-12-21 15:58:49)
                mtime 1513868329.753150507 (2017-12-21 15:58:49)
                otime 1513267009.164686143 (2017-12-14 16:56:49)
        item 12 key (57648595 INODE_REF 57643659) itemoff 3192 itemsize 11
                index 113 namelen 1 name: d
        item 13 key (57648595 DIR_ITEM 3331247447) itemoff 3123 itemsize 69
                location key (58472210 INODE_ITEM 0) type FILE
                transid 89418 data_len 0 name_len 8231
                name: 454bf066ddfbf42e0f3b77ea71c82f-878732.oq
        item 14 key (57648595 DIR_ITEM 3363354030) itemoff 3053 itemsize 70
                location key (57923894 INODE_ITEM 0) type DIR_ITEM.33
                transid 89142 data_len 0 name_len 40
                name: 2f3f379b2a3d7499471edb74869efe-1948311.d
        item 15 key (57648595 DIR_INDEX 435) itemoff 2983 itemsize 70
                location key (57923894 INODE_ITEM 0) type FILE
                transid 89142 data_len 0 name_len 40
                name: 2f3f379b2a3d7499471edb74869efe-1948311.d
        item 16 key (57648595 DIR_INDEX 1137) itemoff 2914 itemsize 69
                location key (58472210 INODE_ITEM 0) type FILE
                transid 89418 data_len 0 name_len 39
                name: 454bf066ddfbf42e0f3b77ea71c82f-878732.o
        item 17 key (57923894 INODE_ITEM 0) itemoff 2754 itemsize 160
                generation 89142 transid 89142 size 36092 nbytes 36864
                block group 0 mode 100644 links 1 uid 1000 gid 1000 rdev 0
                sequence 0 flags 0x91(none)
                atime 1513278413.460486168 (2017-12-14 20:06:53)
                ctime 1513278413.460486168 (2017-12-14 20:06:53)
                mtime 1513278413.460486168 (2017-12-14 20:06:53)
                otime 1513278413.460486168 (2017-12-14 20:06:53)
        item 18 key (57923894 INODE_REF 57648595) itemoff 2704 itemsize 50
                index 435 namelen 40 name: 2f3f379b2a3d7499471edb74869efe-1948311.d
        item 19 key (57923894 EXTENT_DATA 0) itemoff 2651 itemsize 53
                generation 89142 type 1 (regular)
                extent data disk byte 123290755072 nr 36864
                extent data offset 0 nr 36864 ram 36864
                extent compression 0 (none)
        item 20 key (58191388 INODE_ITEM 0) itemoff 2491 itemsize 160
                generation 89259 transid 89259 size 395280 nbytes 397312
                block group 0 mode 100644 links 1 uid 1000 gid 1000 rdev 0
                sequence 0 flags 0xa4(none)
                atime 1513332325.477020047 (2017-12-15 11:05:25)
                ctime 1513332325.477020047 (2017-12-15 11:05:25)
                mtime 1513332325.477020047 (2017-12-15 11:05:25)
                otime 1513332325.477020047 (2017-12-15 11:05:25)
        item 21 key (58191388 INODE_REF 40424284) itemoff 2470 itemsize 21
                index 1094 namelen 11 name: bzImage.tsc
leaf 146426621952 items 46 free space 11 generation 89680 owner 5
leaf 146426621952 flags 0x1(WRITTEN) backref revision 1
fs uuid b3bfb56e-d445-4335-93f0-c1fb2d1f6df1
chunk uuid 732d73c9-d037-4406-8dcb-dfa101bc5a9b
        item 0 key (58191388 EXTENT_DATA 0) itemoff 3942 itemsize 53
                generation 87303 type 1 (regular)
                extent data disk byte 153024724992 nr 397312
                extent data offset 0 nr 397312 ram 397312
                extent compression 0 (none)
        item 1 key (58472210 INODE_ITEM 0) itemoff 3782 itemsize 160
                generation 89418 transid 89419 size 168464 nbytes 172032
                block group 0 mode 100644 links 1 uid 1000 gid 1000 rdev 0
                sequence 0 flags 0x48(none)
                atime 1513868153.15329422 (2017-12-21 15:55:53)
                ctime 1513868153.15329422 (2017-12-21 15:55:53)
                mtime 1513868153.15329422 (2017-12-21 15:55:53)
                otime 1513868153.15329422 (2017-12-21 15:55:53)
        item 2 key (58472210 INODE_REF 57648595) itemoff 3733 itemsize 49
                index 1137 namelen 39 name: 454bf066ddfbf42e0f3b77ea71c82f-878732.o
        item 3 key (58472210 EXTENT_DATA 0) itemoff 3680 itemsize 53
                generation 89419 type 1 (regular)
                extent data disk byte 153083658240 nr 172032
                extent data offset 0 nr 172032 ram 172032
                extent compression 0 (none)
        item 4 key (58477961 INODE_ITEM 0) itemoff 3520 itemsize 160
                generation 89420 transid 89424 size 2 nbytes 0
                block group 0 mode 40755 links 1 uid 1000 gid 1000 rdev 0
                sequence 0 flags 0x1ec(none)
                atime 1513868234.836162788 (2017-12-21 15:57:14)
                ctime 1513868371.49586338 (2017-12-21 15:59:31)
                mtime 1513868371.49586338 (2017-12-21 15:59:31)
                otime 1513868234.836162788 (2017-12-21 15:57:14)
        item 5 key (58477961 INODE_REF 682) itemoff 3509 itemsize 11
                index 59 namelen 1 name: X
        item 6 key (58477961 DIR_ITEM 2828071171) itemoff 3478 itemsize 31
                location key (57643659 INODE_ITEM 0) type DIR
                transid 89420 data_len 0 name_len 1
                name: 4
        item 7 key (58477961 DIR_INDEX 6) itemoff 3447 itemsize 31
                location key (57643659 INODE_ITEM 0) type DIR

> Thanks,
> Qu

Sebastian

Re: invalid files names, btrfs check can't repair it

[Sebastian Andrzej Siewior]

On 2018-01-15 12:23:05 [+0800], Qu Wenruo wrote:
> Right, I'll fix it soon.
> 
> And BTW what makes the the output different from the original one?
> 
> Sebastaian, did you do extra write or other operation to the fs after
> previous btrfs check?

Well the filesystem is in use but there should be no writtes to it since
initial `check' output. The `check' invalidates the space cache that is
rebuilt, not sure if this has any effect. Those two magic files are in a
subfolder of ccache and ccache shouldn't look into it at all.

> Thanks,
> Qu

Sebastian

Re: invalid files names, btrfs check can't repair it

[Qu Wenruo]

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

Now the problems are all located:

For file "2f3f379b2a3d7499471edb74869efe-1948311.d", it's the problem of
its DIR_ITEM has wrong type:

------
        item 14 key (57648595 DIR_ITEM 3363354030) itemoff 3053 itemsize 70
                location key (57923894 INODE_ITEM 0) type DIR_ITEM.33
                                                          ^^^^^^^^^^^
------

There is unexpected type DIR_ITEM and a special number 33 here.

Despite that, the file is completely fine.


For file "454bf066ddfbf42e0f3b77ea71c82f-878732.o"
The problem is its namelen.

------
        item 13 key (57648595 DIR_ITEM 3331247447) itemoff 3123 itemsize 69
                location key (58472210 INODE_ITEM 0) type FILE
                transid 89418 data_len 0 name_len 8231
                                                  ^^^^ Insane
                name: 454bf066ddfbf42e0f3b77ea71c82f-878732.oq
------

Despite that, it should be fine.

I'm not 100% sure if repair can really handle it well.
But I could craft a temporary fix based on btrfs-corrupt-block (I know
the name is scary).
And you may need to compile btrfs-progs with my patch.

The only remaining thing I need is the subvolume id which contains the
corrupted files.

Since there is no other hit, I assume it's root subvolume (5), but I
still need the extra confirm since the fix will be hard-coded.

Thanks,
Qu


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

Re: invalid files names, btrfs check can't repair it

[Qu Wenruo]

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



On 2018年01月16日 12:51, Qu Wenruo wrote:
> Now the problems are all located:
> 
> For file "2f3f379b2a3d7499471edb74869efe-1948311.d", it's the problem of
> its DIR_ITEM has wrong type:
> 
> ------
>         item 14 key (57648595 DIR_ITEM 3363354030) itemoff 3053 itemsize 70
>                 location key (57923894 INODE_ITEM 0) type DIR_ITEM.33
>                                                           ^^^^^^^^^^^
> ------
> 
> There is unexpected type DIR_ITEM and a special number 33 here.
> 
> Despite that, the file is completely fine.
> 
> 
> For file "454bf066ddfbf42e0f3b77ea71c82f-878732.o"
> The problem is its namelen.
> 
> ------
>         item 13 key (57648595 DIR_ITEM 3331247447) itemoff 3123 itemsize 69
>                 location key (58472210 INODE_ITEM 0) type FILE
>                 transid 89418 data_len 0 name_len 8231
>                                                   ^^^^ Insane
>                 name: 454bf066ddfbf42e0f3b77ea71c82f-878732.oq
> ------
> 
> Despite that, it should be fine.
> 
> I'm not 100% sure if repair can really handle it well.
> But I could craft a temporary fix based on btrfs-corrupt-block (I know
> the name is scary).
> And you may need to compile btrfs-progs with my patch.

I just assume it's fs_root, and pushed the hard-coded fix branch to my
github:
https://github.com/adam900710/btrfs-progs/tree/hard_coded_fix_for_sebastian

Usage:
./btrfs-corrupt-block -X <device>

Just as commit message says, if anything went wrong, it will not touch
the fs at all.
So it should be somewhat safe to use.

And if something went wrong, it will cause backtrace and abort, it's
designed and you don't need to panic:

Example: No dir_item in my btrfs
------
./btrfs-corrupt-block -X /dev/data/btrfs
ERROR: corrupted DIR_ITEM not found
extent buffer leak: start 4227072 len 16384
extent_io.c:607: free_extent_buffer_internal: BUG_ON `eb->flags &
EXTENT_DIRTY` triggered, value 1
./btrfs-corrupt-block(+0x251df)[0x5623e003a1df]
./btrfs-corrupt-block(free_extent_buffer_nocache+0x1f)[0x5623e003aac1]
./btrfs-corrupt-block(extent_io_tree_cleanup+0x6d)[0x5623e003ab33]
./btrfs-corrupt-block(btrfs_cleanup_all_caches+0x76)[0x5623e0027747]
./btrfs-corrupt-block(close_ctree_fs_info+0x111)[0x5623e0028027]
./btrfs-corrupt-block(main+0x3f5)[0x5623e00551df]
/usr/lib/libc.so.6(__libc_start_main+0xea)[0x7fdce4e0ff4a]
./btrfs-corrupt-block(_start+0x2a)[0x5623e001ee3a]
Aborted (core dumped)
------

And if above error happens, please paste the error output and provide
the subvolume id.

Thanks,
Qu

> 
> The only remaining thing I need is the subvolume id which contains the
> corrupted files.
> 
> Since there is no other hit, I assume it's root subvolume (5), but I
> still need the extra confirm since the fix will be hard-coded.
> 
> Thanks,
> Qu
> 


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

Re: invalid files names, btrfs check can't repair it

[Sebastian Andrzej Siewior]

On 16 January 2018 05:51:23 CET, Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>Since there is no other hit, I assume it's root subvolume (5), but I
>still need the extra confirm since the fix will be hard-coded.

Yes, 5 is correct.

>
>Thanks,
>Qu



Sebastian

Re: invalid files names, btrfs check can't repair it

[Sebastian Andrzej Siewior]

On 2018-01-16 13:19:50 [+0800], Qu Wenruo wrote:
> Usage:
> ./btrfs-corrupt-block -X <device>
# ./btrfs-corrupt-block -X /dev/sdb4
Fix is done successfully

may I mount it now or should I run btrfs check or something first?

> Thanks,
> Qu

Sebastian

Re: invalid files names, btrfs check can't repair it

[Qu Wenruo]

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



On 2018年01月16日 18:10, Sebastian Andrzej Siewior wrote:
> On 2018-01-16 13:19:50 [+0800], Qu Wenruo wrote:
>> Usage:
>> ./btrfs-corrupt-block -X <device>
> # ./btrfs-corrupt-block -X /dev/sdb4
> Fix is done successfully
> 
> may I mount it now or should I run btrfs check or something first?

Btrfs check is always recommended before really mount it.

However as long as there is no other problem, btrfs check should not
report anything wrong.

Thanks,
Qu
> 
>> Thanks,
>> Qu
> 
> Sebastian
> --
> 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: invalid files names, btrfs check can't repair it

[Sebastian Andrzej Siewior]

On 2018-01-16 18:22:14 [+0800], Qu Wenruo wrote:
> Btrfs check is always recommended before really mount it.

 # btrfs check -p /dev/sdb4 
 Checking filesystem on /dev/sdb4
 UUID: b3bfb56e-d445-4335-93f0-c1fb2d1f6df1
 checking extents [O]
 cache and super generation don't match, space cache will be invalidated
 root 5 inode 57648595 errors 200, dir isize wrong

 ERROR: errors found in fs roots
 found 64009740288 bytes used, error(s) found
 total csum bytes: 61644600
 total tree bytes: 865746944
 total fs tree bytes: 693469184
 total extent tree bytes: 84905984
 btree space waste bytes: 225096302
 file data blocks allocated: 63203807232
  referenced 63142268928

> However as long as there is no other problem, btrfs check should not
> report anything wrong.

Is it important to note that the filesystem is a raid1 one?

> Thanks,
> Qu

Sebastian

Re: invalid files names, btrfs check can't repair it

[Qu Wenruo]

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



On 2018年01月16日 18:49, Sebastian Andrzej Siewior wrote:
> On 2018-01-16 18:22:14 [+0800], Qu Wenruo wrote:
>> Btrfs check is always recommended before really mount it.
> 
>  # btrfs check -p /dev/sdb4 
>  Checking filesystem on /dev/sdb4
>  UUID: b3bfb56e-d445-4335-93f0-c1fb2d1f6df1
>  checking extents [O]
>  cache and super generation don't match, space cache will be invalidated
>  root 5 inode 57648595 errors 200, dir isize wrong

This is a very minor problem.

btrfs check --repair should handle it without problem.

Or just ignore it if you don't trust check --repair.

> 
>  ERROR: errors found in fs roots
>  found 64009740288 bytes used, error(s) found
>  total csum bytes: 61644600
>  total tree bytes: 865746944
>  total fs tree bytes: 693469184
>  total extent tree bytes: 84905984
>  btree space waste bytes: 225096302
>  file data blocks allocated: 63203807232
>   referenced 63142268928
> 
>> However as long as there is no other problem, btrfs check should not
>> report anything wrong.
> 
> Is it important to note that the filesystem is a raid1 one?

Nope, the repair code handles any chunk profile well.

Thanks,
Qu

> 
>> Thanks,
>> Qu
> 
> Sebastian
> 


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

Re: invalid files names, btrfs check can't repair it

[Sebastian Andrzej Siewior]

On 2018-01-16 19:20:56 [+0800], Qu Wenruo wrote:
> This is a very minor problem.
> 
> btrfs check --repair should handle it without problem.

awesome, thank you! After the --repair completed, the following didn't
report the error anymore. And now I was able to remove the two files.
Thank you.

> Thanks,
> Qu

Sebastian

Re: invalid files names, btrfs check can't repair it

[Qu Wenruo]

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



On 2018年01月16日 20:15, Sebastian Andrzej Siewior wrote:
> On 2018-01-16 19:20:56 [+0800], Qu Wenruo wrote:
>> This is a very minor problem.
>>
>> btrfs check --repair should handle it without problem.
> 
> awesome, thank you! After the --repair completed, the following didn't
> report the error anymore. And now I was able to remove the two files.
> Thank you.

And thanks for your report on this issue too, I'm working on the generic
repair function for such type mismatch and name len mismatch.

It would be soon to see such repair function in btrfs-progs, and no need
to bother using any hard coded fixer.

(Just a little spoiler, the repair functionality will land in lowmem
mode first, as lowmem mode already have such infrastructure to address
it, although if executed with mainline btrfs-progs, it will just worse
the problem)

Thanks,
Qu

> 
>> Thanks,
>> Qu
> 
> Sebastian
> --
> 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 --]