All of lore.kernel.org
 help / color / mirror / Atom feed
* btrfs check fail
@ 2022-04-23  3:56 Jat
  2022-04-23  4:53 ` Qu Wenruo
  0 siblings, 1 reply; 5+ messages in thread
From: Jat @ 2022-04-23  3:56 UTC (permalink / raw)
  To: linux-btrfs

Hello,
I am trying to resize a partition offline, but it fails the check.
The output of running btrfs check manually is below, can you please advise me how to resolve the issues?

Here is the output from btrfs check:
sudo btrfs check /dev/sda7
Opening filesystem to check...
Checking filesystem on /dev/sda7
UUID: 4599055f-785a-4843-9f59-5b04e84fea1a
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
cache and super generation don't match, space cache will be invalidated
[4/7] checking fs roots
root 267 inode 249749 errors 1040, bad file extent, some csum missing
root 268 inode 466 errors 1040, bad file extent, some csum missing
root 308 inode 249749 errors 1040, bad file extent, some csum missing
root 313 inode 466 errors 1040, bad file extent, some csum missing
ERROR: errors found in fs roots
found 103264391173 bytes used, error(s) found
total csum bytes: 93365076
total tree bytes: 2113994752
total fs tree bytes: 1825112064
total extent tree bytes: 144097280
btree space waste bytes: 432782214
file data blocks allocated: 352758886400
 referenced 178094907392


Here is the requested info from Live boot environment for offline partition sizing & btrfs check...
uname -a
Linux manjaro 5.15.32-1-MANJARO #1 SMP PREEMPT Mon Mar 28 09:16:36 UTC 2022 x86_64 GNU/Linux

dmesg > dmesg.log
[Sorry, didn't capture this after running the check in live boot environment. Will capture as needed next time along with recommendation]


Here is the requested info from within mounted environment...
uname -a
Linux manjaro-desktop 5.17.1-3-MANJARO #1 SMP PREEMPT Thu Mar 31 12:27:24 UTC 2022 x86_64 GNU/Linux

btrfs --version
btrfs-progs v5.16.2

sudo btrfs fi show
Label: 'manjaro-kde'  uuid: 4599055f-785a-4843-9f59-5b04e84fea1a
        Total devices 1 FS bytes used 96.19GiB
        devid    1 size 226.34GiB used 226.34GiB path /dev/sda7

btrfs fi df /
Data, single: total=220.33GiB, used=94.92GiB
System, single: total=4.00MiB, used=48.00KiB
Metadata, single: total=6.01GiB, used=1.97GiB
GlobalReserve, single: total=275.20MiB, used=0.00B


Thank you,
Jat

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: btrfs check fail
  2022-04-23  3:56 btrfs check fail Jat
@ 2022-04-23  4:53 ` Qu Wenruo
  2022-04-23 17:40   ` Jat
  0 siblings, 1 reply; 5+ messages in thread
From: Qu Wenruo @ 2022-04-23  4:53 UTC (permalink / raw)
  To: Jat, linux-btrfs



On 2022/4/23 11:56, Jat wrote:
> Hello,
> I am trying to resize a partition offline, but it fails the check.
> The output of running btrfs check manually is below, can you please advise me how to resolve the issues?
>
> Here is the output from btrfs check:
> sudo btrfs check /dev/sda7
> Opening filesystem to check...
> Checking filesystem on /dev/sda7
> UUID: 4599055f-785a-4843-9f59-5b04e84fea1a
> [1/7] checking root items
> [2/7] checking extents
> [3/7] checking free space cache
> cache and super generation don't match, space cache will be invalidated

Recommended to go v2 cache.

You can just mount it with space_cache=v2.

> [4/7] checking fs roots
> root 267 inode 249749 errors 1040, bad file extent, some csum missing
> root 268 inode 466 errors 1040, bad file extent, some csum missing
> root 308 inode 249749 errors 1040, bad file extent, some csum missing
> root 313 inode 466 errors 1040, bad file extent, some csum missing

Please run "btrfs check --mode=lowmem" to provide a more readable output.

There are several different reasons to cause the "bad file extent".

 From inline extents for non-zero offset, to compressed file extents for
NODATASUM inodes.

The later case can explain all your problems in one go, and can be
caused by older kernels.

If that's the case, you can just go copy the files to other locations
and remove the old file, and call it a day.

Thanks,
Qu

> ERROR: errors found in fs roots
> found 103264391173 bytes used, error(s) found
> total csum bytes: 93365076
> total tree bytes: 2113994752
> total fs tree bytes: 1825112064
> total extent tree bytes: 144097280
> btree space waste bytes: 432782214
> file data blocks allocated: 352758886400
>   referenced 178094907392
>
>
> Here is the requested info from Live boot environment for offline partition sizing & btrfs check...
> uname -a
> Linux manjaro 5.15.32-1-MANJARO #1 SMP PREEMPT Mon Mar 28 09:16:36 UTC 2022 x86_64 GNU/Linux
>
> dmesg > dmesg.log
> [Sorry, didn't capture this after running the check in live boot environment. Will capture as needed next time along with recommendation]
>
>
> Here is the requested info from within mounted environment...
> uname -a
> Linux manjaro-desktop 5.17.1-3-MANJARO #1 SMP PREEMPT Thu Mar 31 12:27:24 UTC 2022 x86_64 GNU/Linux
>
> btrfs --version
> btrfs-progs v5.16.2
>
> sudo btrfs fi show
> Label: 'manjaro-kde'  uuid: 4599055f-785a-4843-9f59-5b04e84fea1a
>          Total devices 1 FS bytes used 96.19GiB
>          devid    1 size 226.34GiB used 226.34GiB path /dev/sda7
>
> btrfs fi df /
> Data, single: total=220.33GiB, used=94.92GiB
> System, single: total=4.00MiB, used=48.00KiB
> Metadata, single: total=6.01GiB, used=1.97GiB
> GlobalReserve, single: total=275.20MiB, used=0.00B
>
>
> Thank you,
> Jat

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: btrfs check fail
  2022-04-23  4:53 ` Qu Wenruo
@ 2022-04-23 17:40   ` Jat
  2022-04-23 22:25     ` Jat
  0 siblings, 1 reply; 5+ messages in thread
From: Jat @ 2022-04-23 17:40 UTC (permalink / raw)
  To: Qu Wenruo, linux-btrfs

Thanks very much, Qu!
I attempted your advise, but was only partially successful.

> Recommended to go v2 cache.
Done, no problem.

> just go copy the files to other locations and remove the old file
This is where I had trouble.
I tried on just one file to start:
/mnt/@_190127freshinstall/var/log/journal/b0eb202aa367415fb973e99ecd54889e/user-1000.journal

I made a copy, deleted the original, and then renamed back to original:
cp user-1000.journal user-1000.journal.temp2
rm user-1000.journal
mv user-1000.journal.temp2 user-1000.journal

But afterward I got the same error, just different inode:
Pre: root 267 inode 249749 errors 1040, bad file extent, some csum missing
Post: root 267 inode 249772 errors 1040, bad file extent, some csum missing

What have I done wrong?

Thanks again for your help!

Regards,
Jat


----- Original message -----
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Jat <btrfs@jat.fastmail.com>, linux-btrfs@vger.kernel.org
Subject: Re: btrfs check fail
Date: Friday, April 22, 2022 9:53 PM



On 2022/4/23 11:56, Jat wrote:
> Hello,
> I am trying to resize a partition offline, but it fails the check.
> The output of running btrfs check manually is below, can you please advise me how to resolve the issues?
>
> Here is the output from btrfs check:
> sudo btrfs check /dev/sda7
> Opening filesystem to check...
> Checking filesystem on /dev/sda7
> UUID: 4599055f-785a-4843-9f59-5b04e84fea1a
> [1/7] checking root items
> [2/7] checking extents
> [3/7] checking free space cache
> cache and super generation don't match, space cache will be invalidated

Recommended to go v2 cache.

You can just mount it with space_cache=v2.

> [4/7] checking fs roots
> root 267 inode 249749 errors 1040, bad file extent, some csum missing
> root 268 inode 466 errors 1040, bad file extent, some csum missing
> root 308 inode 249749 errors 1040, bad file extent, some csum missing
> root 313 inode 466 errors 1040, bad file extent, some csum missing

Please run "btrfs check --mode=lowmem" to provide a more readable output.

There are several different reasons to cause the "bad file extent".

 From inline extents for non-zero offset, to compressed file extents for
NODATASUM inodes.

The later case can explain all your problems in one go, and can be
caused by older kernels.

If that's the case, you can just go copy the files to other locations
and remove the old file, and call it a day.

Thanks,
Qu

> ERROR: errors found in fs roots
> found 103264391173 bytes used, error(s) found
> total csum bytes: 93365076
> total tree bytes: 2113994752
> total fs tree bytes: 1825112064
> total extent tree bytes: 144097280
> btree space waste bytes: 432782214
> file data blocks allocated: 352758886400
>   referenced 178094907392
>
>
> Here is the requested info from Live boot environment for offline partition sizing & btrfs check...
> uname -a
> Linux manjaro 5.15.32-1-MANJARO #1 SMP PREEMPT Mon Mar 28 09:16:36 UTC 2022 x86_64 GNU/Linux
>
> dmesg > dmesg.log
> [Sorry, didn't capture this after running the check in live boot environment. Will capture as needed next time along with recommendation]
>
>
> Here is the requested info from within mounted environment...
> uname -a
> Linux manjaro-desktop 5.17.1-3-MANJARO #1 SMP PREEMPT Thu Mar 31 12:27:24 UTC 2022 x86_64 GNU/Linux
>
> btrfs --version
> btrfs-progs v5.16.2
>
> sudo btrfs fi show
> Label: 'manjaro-kde'  uuid: 4599055f-785a-4843-9f59-5b04e84fea1a
>          Total devices 1 FS bytes used 96.19GiB
>          devid    1 size 226.34GiB used 226.34GiB path /dev/sda7
>
> btrfs fi df /
> Data, single: total=220.33GiB, used=94.92GiB
> System, single: total=4.00MiB, used=48.00KiB
> Metadata, single: total=6.01GiB, used=1.97GiB
> GlobalReserve, single: total=275.20MiB, used=0.00B
>
>
> Thank you,
> Jat

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: btrfs check fail
  2022-04-23 17:40   ` Jat
@ 2022-04-23 22:25     ` Jat
  2022-04-23 22:32       ` Qu Wenruo
  0 siblings, 1 reply; 5+ messages in thread
From: Jat @ 2022-04-23 22:25 UTC (permalink / raw)
  To: Qu Wenruo, linux-btrfs

Okay, I got it resolved, btrfs check passed and partition moved & resized successfully.
Solution was to move the files to a different filesystem and back.

Thanks again!
Jat

----- Original message -----
From: Jat <btrfs@jat.fastmail.com>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>, linux-btrfs@vger.kernel.org
Subject: Re: btrfs check fail
Date: Saturday, April 23, 2022 10:40 AM

Thanks very much, Qu!
I attempted your advise, but was only partially successful.

> Recommended to go v2 cache.
Done, no problem.

> just go copy the files to other locations and remove the old file
This is where I had trouble.
I tried on just one file to start:
/mnt/@_190127freshinstall/var/log/journal/b0eb202aa367415fb973e99ecd54889e/user-1000.journal

I made a copy, deleted the original, and then renamed back to original:
cp user-1000.journal user-1000.journal.temp2
rm user-1000.journal
mv user-1000.journal.temp2 user-1000.journal

But afterward I got the same error, just different inode:
Pre: root 267 inode 249749 errors 1040, bad file extent, some csum missing
Post: root 267 inode 249772 errors 1040, bad file extent, some csum missing

What have I done wrong?

Thanks again for your help!

Regards,
Jat


----- Original message -----
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Jat <btrfs@jat.fastmail.com>, linux-btrfs@vger.kernel.org
Subject: Re: btrfs check fail
Date: Friday, April 22, 2022 9:53 PM



On 2022/4/23 11:56, Jat wrote:
> Hello,
> I am trying to resize a partition offline, but it fails the check.
> The output of running btrfs check manually is below, can you please advise me how to resolve the issues?
>
> Here is the output from btrfs check:
> sudo btrfs check /dev/sda7
> Opening filesystem to check...
> Checking filesystem on /dev/sda7
> UUID: 4599055f-785a-4843-9f59-5b04e84fea1a
> [1/7] checking root items
> [2/7] checking extents
> [3/7] checking free space cache
> cache and super generation don't match, space cache will be invalidated

Recommended to go v2 cache.

You can just mount it with space_cache=v2.

> [4/7] checking fs roots
> root 267 inode 249749 errors 1040, bad file extent, some csum missing
> root 268 inode 466 errors 1040, bad file extent, some csum missing
> root 308 inode 249749 errors 1040, bad file extent, some csum missing
> root 313 inode 466 errors 1040, bad file extent, some csum missing

Please run "btrfs check --mode=lowmem" to provide a more readable output.

There are several different reasons to cause the "bad file extent".

 From inline extents for non-zero offset, to compressed file extents for
NODATASUM inodes.

The later case can explain all your problems in one go, and can be
caused by older kernels.

If that's the case, you can just go copy the files to other locations
and remove the old file, and call it a day.

Thanks,
Qu

> ERROR: errors found in fs roots
> found 103264391173 bytes used, error(s) found
> total csum bytes: 93365076
> total tree bytes: 2113994752
> total fs tree bytes: 1825112064
> total extent tree bytes: 144097280
> btree space waste bytes: 432782214
> file data blocks allocated: 352758886400
>   referenced 178094907392
>
>
> Here is the requested info from Live boot environment for offline partition sizing & btrfs check...
> uname -a
> Linux manjaro 5.15.32-1-MANJARO #1 SMP PREEMPT Mon Mar 28 09:16:36 UTC 2022 x86_64 GNU/Linux
>
> dmesg > dmesg.log
> [Sorry, didn't capture this after running the check in live boot environment. Will capture as needed next time along with recommendation]
>
>
> Here is the requested info from within mounted environment...
> uname -a
> Linux manjaro-desktop 5.17.1-3-MANJARO #1 SMP PREEMPT Thu Mar 31 12:27:24 UTC 2022 x86_64 GNU/Linux
>
> btrfs --version
> btrfs-progs v5.16.2
>
> sudo btrfs fi show
> Label: 'manjaro-kde'  uuid: 4599055f-785a-4843-9f59-5b04e84fea1a
>          Total devices 1 FS bytes used 96.19GiB
>          devid    1 size 226.34GiB used 226.34GiB path /dev/sda7
>
> btrfs fi df /
> Data, single: total=220.33GiB, used=94.92GiB
> System, single: total=4.00MiB, used=48.00KiB
> Metadata, single: total=6.01GiB, used=1.97GiB
> GlobalReserve, single: total=275.20MiB, used=0.00B
>
>
> Thank you,
> Jat

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: btrfs check fail
  2022-04-23 22:25     ` Jat
@ 2022-04-23 22:32       ` Qu Wenruo
  0 siblings, 0 replies; 5+ messages in thread
From: Qu Wenruo @ 2022-04-23 22:32 UTC (permalink / raw)
  To: Jat, linux-btrfs



On 2022/4/24 06:25, Jat wrote:
> Okay, I got it resolved, btrfs check passed and partition moved & resized successfully.
> Solution was to move the files to a different filesystem and back.

That's one solution that will always work.

The other way is to use "cp --reflink=never".
My bad, I forgot cp will try to use reflink to skip IO, thus in btrfs it
will not really do the proper IO.

Thanks,
Qu
>
> Thanks again!
> Jat
>
> ----- Original message -----
> From: Jat <btrfs@jat.fastmail.com>
> To: Qu Wenruo <quwenruo.btrfs@gmx.com>, linux-btrfs@vger.kernel.org
> Subject: Re: btrfs check fail
> Date: Saturday, April 23, 2022 10:40 AM
>
> Thanks very much, Qu!
> I attempted your advise, but was only partially successful.
>
>> Recommended to go v2 cache.
> Done, no problem.
>
>> just go copy the files to other locations and remove the old file
> This is where I had trouble.
> I tried on just one file to start:
> /mnt/@_190127freshinstall/var/log/journal/b0eb202aa367415fb973e99ecd54889e/user-1000.journal
>
> I made a copy, deleted the original, and then renamed back to original:
> cp user-1000.journal user-1000.journal.temp2
> rm user-1000.journal
> mv user-1000.journal.temp2 user-1000.journal
>
> But afterward I got the same error, just different inode:
> Pre: root 267 inode 249749 errors 1040, bad file extent, some csum missing
> Post: root 267 inode 249772 errors 1040, bad file extent, some csum missing
>
> What have I done wrong?
>
> Thanks again for your help!
>
> Regards,
> Jat
>
>
> ----- Original message -----
> From: Qu Wenruo <quwenruo.btrfs@gmx.com>
> To: Jat <btrfs@jat.fastmail.com>, linux-btrfs@vger.kernel.org
> Subject: Re: btrfs check fail
> Date: Friday, April 22, 2022 9:53 PM
>
>
>
> On 2022/4/23 11:56, Jat wrote:
>> Hello,
>> I am trying to resize a partition offline, but it fails the check.
>> The output of running btrfs check manually is below, can you please advise me how to resolve the issues?
>>
>> Here is the output from btrfs check:
>> sudo btrfs check /dev/sda7
>> Opening filesystem to check...
>> Checking filesystem on /dev/sda7
>> UUID: 4599055f-785a-4843-9f59-5b04e84fea1a
>> [1/7] checking root items
>> [2/7] checking extents
>> [3/7] checking free space cache
>> cache and super generation don't match, space cache will be invalidated
>
> Recommended to go v2 cache.
>
> You can just mount it with space_cache=v2.
>
>> [4/7] checking fs roots
>> root 267 inode 249749 errors 1040, bad file extent, some csum missing
>> root 268 inode 466 errors 1040, bad file extent, some csum missing
>> root 308 inode 249749 errors 1040, bad file extent, some csum missing
>> root 313 inode 466 errors 1040, bad file extent, some csum missing
>
> Please run "btrfs check --mode=lowmem" to provide a more readable output.
>
> There are several different reasons to cause the "bad file extent".
>
>   From inline extents for non-zero offset, to compressed file extents for
> NODATASUM inodes.
>
> The later case can explain all your problems in one go, and can be
> caused by older kernels.
>
> If that's the case, you can just go copy the files to other locations
> and remove the old file, and call it a day.
>
> Thanks,
> Qu
>
>> ERROR: errors found in fs roots
>> found 103264391173 bytes used, error(s) found
>> total csum bytes: 93365076
>> total tree bytes: 2113994752
>> total fs tree bytes: 1825112064
>> total extent tree bytes: 144097280
>> btree space waste bytes: 432782214
>> file data blocks allocated: 352758886400
>>    referenced 178094907392
>>
>>
>> Here is the requested info from Live boot environment for offline partition sizing & btrfs check...
>> uname -a
>> Linux manjaro 5.15.32-1-MANJARO #1 SMP PREEMPT Mon Mar 28 09:16:36 UTC 2022 x86_64 GNU/Linux
>>
>> dmesg > dmesg.log
>> [Sorry, didn't capture this after running the check in live boot environment. Will capture as needed next time along with recommendation]
>>
>>
>> Here is the requested info from within mounted environment...
>> uname -a
>> Linux manjaro-desktop 5.17.1-3-MANJARO #1 SMP PREEMPT Thu Mar 31 12:27:24 UTC 2022 x86_64 GNU/Linux
>>
>> btrfs --version
>> btrfs-progs v5.16.2
>>
>> sudo btrfs fi show
>> Label: 'manjaro-kde'  uuid: 4599055f-785a-4843-9f59-5b04e84fea1a
>>           Total devices 1 FS bytes used 96.19GiB
>>           devid    1 size 226.34GiB used 226.34GiB path /dev/sda7
>>
>> btrfs fi df /
>> Data, single: total=220.33GiB, used=94.92GiB
>> System, single: total=4.00MiB, used=48.00KiB
>> Metadata, single: total=6.01GiB, used=1.97GiB
>> GlobalReserve, single: total=275.20MiB, used=0.00B
>>
>>
>> Thank you,
>> Jat

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2022-04-23 22:32 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-23  3:56 btrfs check fail Jat
2022-04-23  4:53 ` Qu Wenruo
2022-04-23 17:40   ` Jat
2022-04-23 22:25     ` Jat
2022-04-23 22:32       ` Qu Wenruo

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.