Tree-checker Issue / Corrupt FS after upgrade ?

Tree-checker Issue / Corrupt FS after upgrade ?

[benjamin.haendel]

Hi,

i have been running my little Storage (32TB) on a Ubuntu 18.04 LTS Machine
with btrfs-progs 4.17. I then did my monthly upgrade (apt dist-upgrade) and
after a reboot my Partition could not mount with the error message: 
"root@Userv:/home/benjamin# mount -r ro btrfs /dev/mapper/Crypto
/media/Storage
mount: bad usage"

I then proceeded to run a btrfs check which gave thousands of errors and
then also a super-recover:
root@Userv:/home/benjamin# btrfs rescue super-recover -v /dev/mapper/Crypto
All Devices:
Device: id = 1, name = /dev/mapper/Crypto

Before Recovering:
[All good supers]:
device name = /dev/mapper/Crypto
superblock bytenr = 65536

device name = /dev/mapper/Crypto
superblock bytenr = 67108864

device name = /dev/mapper/Crypto
superblock bytenr = 274877906944

[All bad supers]:

All supers are valid, no need to recover

I now checked my dmesg log:
[45907.451840] BTRFS critical (device dm-0): corrupt leaf:
block=22751711027200 slot=1 extent bytenr=6754755866624 len=4096 invalid
generation, have 22795412619264 expect (0, 207589]
[45907.451848] BTRFS error (device dm-0): block=22751711027200 read time
tree block corruption detected
[45907.451892] BTRFS error (device dm-0): failed to read block groups: -5
[45907.510712] BTRFS error (device dm-0): open_ctree failed

Google inquiries to this topic led me to this link:
https://btrfs.wiki.kernel.org/index.php/Tree-checker
It tells me to mail here first so thats what i am doing. I kind of suspect
since everything worked perfect (Memtest also no errors) before the update,
it has to do something with that update. I am wondering if it would help if
i deleted my OS Disk and reinstalled an older Version of Ubuntu, like
16.04.6 LTS ?

Since then i upgraded to 20.04 LTS with BTRFS-PROGS 5.7 as a lot of forum
entries said it would be wise to use the newer versions as older were buggy.
That brought no help as well.

Since i am no Linux/Unix Expert i thought it might be better to ask now
first as advised in the link above before proceeding with any other plans.

I find it hard to believe that all data is gone, i feel its buggy behavior
as the partition and everything is still there:
root@Userv:/home/benjamin# btrfs fi show
Label: 'Storage'  uuid: 46c7d04a-d6ac-45be-94cc-724919faca2b
Total devices 1 FS bytes used 28.23TiB
devid    1 size 29.10TiB used 29.04TiB path /dev/mapper/Crypto

Best Regards,
Benjamin Händel

Re: Tree-checker Issue / Corrupt FS after upgrade ?

[Qu Wenruo]

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



On 2020/8/13 上午12:58, benjamin.haendel@gmx.net wrote:
> Hi,
> 
> i have been running my little Storage (32TB) on a Ubuntu 18.04 LTS Machine
> with btrfs-progs 4.17. I then did my monthly upgrade (apt dist-upgrade) and
> after a reboot my Partition could not mount with the error message: 
> "root@Userv:/home/benjamin# mount -r ro btrfs /dev/mapper/Crypto
> /media/Storage
> mount: bad usage"
> 
> I then proceeded to run a btrfs check which gave thousands of errors and
> then also a super-recover:
> root@Userv:/home/benjamin# btrfs rescue super-recover -v /dev/mapper/Crypto
> All Devices:
> Device: id = 1, name = /dev/mapper/Crypto
> 
> Before Recovering:
> [All good supers]:
> device name = /dev/mapper/Crypto
> superblock bytenr = 65536
> 
> device name = /dev/mapper/Crypto
> superblock bytenr = 67108864
> 
> device name = /dev/mapper/Crypto
> superblock bytenr = 274877906944
> 
> [All bad supers]:
> 
> All supers are valid, no need to recover
> 
> I now checked my dmesg log:
> [45907.451840] BTRFS critical (device dm-0): corrupt leaf:
> block=22751711027200 slot=1 extent bytenr=6754755866624 len=4096 invalid
> generation, have 22795412619264 expect (0, 207589]

This is caused by older kernel, which writes some uninitialized value
onto disk.

You can try to fix it with this branch:
https://github.com/adam900710/btrfs-progs/tree/extent_gen_repair

Or you can use older kernel to delete the offending extents.

Thanks,
Qu

> [45907.451848] BTRFS error (device dm-0): block=22751711027200 read time
> tree block corruption detected
> [45907.451892] BTRFS error (device dm-0): failed to read block groups: -5
> [45907.510712] BTRFS error (device dm-0): open_ctree failed
> 
> Google inquiries to this topic led me to this link:
> https://btrfs.wiki.kernel.org/index.php/Tree-checker
> It tells me to mail here first so thats what i am doing. I kind of suspect
> since everything worked perfect (Memtest also no errors) before the update,
> it has to do something with that update. I am wondering if it would help if
> i deleted my OS Disk and reinstalled an older Version of Ubuntu, like
> 16.04.6 LTS ?
> 
> Since then i upgraded to 20.04 LTS with BTRFS-PROGS 5.7 as a lot of forum
> entries said it would be wise to use the newer versions as older were buggy.
> That brought no help as well.
> 
> Since i am no Linux/Unix Expert i thought it might be better to ask now
> first as advised in the link above before proceeding with any other plans.
> 
> I find it hard to believe that all data is gone, i feel its buggy behavior
> as the partition and everything is still there:
> root@Userv:/home/benjamin# btrfs fi show
> Label: 'Storage'  uuid: 46c7d04a-d6ac-45be-94cc-724919faca2b
> Total devices 1 FS bytes used 28.23TiB
> devid    1 size 29.10TiB used 29.04TiB path /dev/mapper/Crypto
> 
> Best Regards,
> Benjamin Händel
> 


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

Re: AW: Tree-checker Issue / Corrupt FS after upgrade ?

[Qu Wenruo]

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



On 2020/8/13 上午7:10, benjamin.haendel@gmx.net wrote:
> Hi Qu,
> 
> thanks for your reply, i am not sure what to do from here on.
> What do i have to download from here or compile/make/install etc. ?

You need to compile that branch.

For how to compile, please check the README.md.


> 
> I'm no total idiot but i still don't understand what i have to get
> And how to apply it...sorry :(

Or you can use btrfs-send to send out the content of your fs with older
kernel, and create a new fs using newer kernel, then receive the stream.

The uninitialized data is only in extent tree, which won't be sent with
the stream, by receiving it with newer kernel, you won't lose anything.

Thanks,
Qu

> 
> Best Regards,
> Ben
> 
> -----Ursprüngliche Nachricht-----
> Von: Qu Wenruo <quwenruo.btrfs@gmx.com> 
> Gesendet: Donnerstag, 13. August 2020 00:51
> An: benjamin.haendel@gmx.net; linux-btrfs@vger.kernel.org
> Betreff: Re: Tree-checker Issue / Corrupt FS after upgrade ?
> 
> 
> 
> On 2020/8/13 上午12:58, benjamin.haendel@gmx.net wrote:
>> Hi,
>>
>> i have been running my little Storage (32TB) on a Ubuntu 18.04 LTS 
>> Machine with btrfs-progs 4.17. I then did my monthly upgrade (apt 
>> dist-upgrade) and after a reboot my Partition could not mount with the error message:
>> "root@Userv:/home/benjamin# mount -r ro btrfs /dev/mapper/Crypto 
>> /media/Storage
>> mount: bad usage"
>>
>> I then proceeded to run a btrfs check which gave thousands of errors 
>> and then also a super-recover:
>> root@Userv:/home/benjamin# btrfs rescue super-recover -v 
>> /dev/mapper/Crypto All Devices:
>> Device: id = 1, name = /dev/mapper/Crypto
>>
>> Before Recovering:
>> [All good supers]:
>> device name = /dev/mapper/Crypto
>> superblock bytenr = 65536
>>
>> device name = /dev/mapper/Crypto
>> superblock bytenr = 67108864
>>
>> device name = /dev/mapper/Crypto
>> superblock bytenr = 274877906944
>>
>> [All bad supers]:
>>
>> All supers are valid, no need to recover
>>
>> I now checked my dmesg log:
>> [45907.451840] BTRFS critical (device dm-0): corrupt leaf:
>> block=22751711027200 slot=1 extent bytenr=6754755866624 len=4096 
>> invalid generation, have 22795412619264 expect (0, 207589]
> 
> This is caused by older kernel, which writes some uninitialized value onto disk.
> 
> You can try to fix it with this branch:
> https://github.com/adam900710/btrfs-progs/tree/extent_gen_repair
> 
> Or you can use older kernel to delete the offending extents.
> 
> Thanks,
> Qu
> 
>> [45907.451848] BTRFS error (device dm-0): block=22751711027200 read 
>> time tree block corruption detected [45907.451892] BTRFS error (device 
>> dm-0): failed to read block groups: -5 [45907.510712] BTRFS error 
>> (device dm-0): open_ctree failed
>>
>> Google inquiries to this topic led me to this link:
>> https://btrfs.wiki.kernel.org/index.php/Tree-checker
>> It tells me to mail here first so thats what i am doing. I kind of 
>> suspect since everything worked perfect (Memtest also no errors) 
>> before the update, it has to do something with that update. I am 
>> wondering if it would help if i deleted my OS Disk and reinstalled an 
>> older Version of Ubuntu, like
>> 16.04.6 LTS ?
>>
>> Since then i upgraded to 20.04 LTS with BTRFS-PROGS 5.7 as a lot of 
>> forum entries said it would be wise to use the newer versions as older were buggy.
>> That brought no help as well.
>>
>> Since i am no Linux/Unix Expert i thought it might be better to ask 
>> now first as advised in the link above before proceeding with any other plans.
>>
>> I find it hard to believe that all data is gone, i feel its buggy 
>> behavior as the partition and everything is still there:
>> root@Userv:/home/benjamin# btrfs fi show
>> Label: 'Storage'  uuid: 46c7d04a-d6ac-45be-94cc-724919faca2b
>> Total devices 1 FS bytes used 28.23TiB
>> devid    1 size 29.10TiB used 29.04TiB path /dev/mapper/Crypto
>>
>> Best Regards,
>> Benjamin Händel
>>
> 
> 


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

Re: AW: AW: Tree-checker Issue / Corrupt FS after upgrade ?

[Qu Wenruo]

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



On 2020/8/14 上午3:34, benjamin.haendel@gmx.net wrote:
> Hi Qu,
> 
> thanks for your help and support, but it is still not clear to me how to download and compile that branch.
> The newest Version that i can find under releases is from "10 Dec 2014 v3.18-rc1 … 1519ee3  zip  tar.gz"

You need to grab it using git, and grab that specific branch, not
downing the zip.

> 
> Also if i finally do understand how to download it am i correct to assume, that i will need to remove current btrfs-progs 5.7
> And install the branch here instead ?

You can compile the branch, and just run that built btrfs without
installing.

But considering the skills needed, I recommend you go the send method.

Just boot using the last working kernel, send out the stream.
Then re-make the fs using latest kernel, and receive the stream.

Or, you can wait your distro to ship v5.9 btrfs-progs (maybe months
away), meanwhile you can still use your older kernel without any problem.

Thanks,
Qu

> 
> Best Regards,
> Ben
> 
> -----Ursprüngliche Nachricht-----
> Von: Qu Wenruo <quwenruo.btrfs@gmx.com> 
> Gesendet: Donnerstag, 13. August 2020 01:30
> An: benjamin.haendel@gmx.net; linux-btrfs@vger.kernel.org
> Betreff: Re: AW: Tree-checker Issue / Corrupt FS after upgrade ?
> 
> 
> 
> On 2020/8/13 上午7:10, benjamin.haendel@gmx.net wrote:
>> Hi Qu,
>>
>> thanks for your reply, i am not sure what to do from here on.
>> What do i have to download from here or compile/make/install etc. ?
> 
> You need to compile that branch.
> 
> For how to compile, please check the README.md.
> 
> 
>>
>> I'm no total idiot but i still don't understand what i have to get And 
>> how to apply it...sorry :(
> 
> Or you can use btrfs-send to send out the content of your fs with older kernel, and create a new fs using newer kernel, then receive the stream.
> 
> The uninitialized data is only in extent tree, which won't be sent with the stream, by receiving it with newer kernel, you won't lose anything.
> 
> Thanks,
> Qu 
> 
> 


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

Re: AW: AW: Tree-checker Issue / Corrupt FS after upgrade ?

[Qu Wenruo]

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



On 2020/8/14 上午5:01, benjamin.haendel@gmx.net wrote:
> Hi Qu,
> 
> i downloaded the code, compiled and installed it.

You still need to run "btrfs check --repair".

Considering you haven't post that output, I guess you didn't run that.

> Still could not mount the FS with error:
> mount: /media/Storage: wrong fs type, bad option, bad superblock on /dev/mapper/Crypto, missing codepage or helper program, or other error.
> 
> Dmesg is telling me:
> [  174.061205] Btrfs loaded, crc32c=crc32c-intel
> [  174.081002] BTRFS: device label Storage devid 1 transid 207602 /dev/dm-0
> [  192.175157] BTRFS info (device dm-0): disk space caching is enabled
> [  204.025699] BTRFS critical (device dm-0): corrupt leaf: block=22751711027200 slot=1 extent bytenr=6754755866624 len=4096 invalid generation, have 22795412619264 expect (0, 207603]
> [  204.025703] BTRFS error (device dm-0): block=22751711027200 read time tree block corruption detected
> [  204.025731] BTRFS error (device dm-0): failed to read block groups: -5
> [  204.076709] BTRFS error (device dm-0): open_ctree failed
> 
> I am unsure of what to do now. Did i have to run a btrfs check --repair with the compiled btrfs branch ?

Yes.

> I also removed all other versions of btrfs now to see if an old version could read it, it now says:
> root@Userv:~# btrfs --version
> btrfs-progs v4.1

Nope, you're not using the correct version.

> 
> Still i can not mount the drive. How can i at least get read access to my data ?

Just go using your older kernel, and wait for your distro to provide
newer enough btrfs-progs.

Thanks,
Qu

> 
> Best Regards,
> Ben
> 
> -----Ursprüngliche Nachricht-----
> Von: Qu Wenruo <quwenruo.btrfs@gmx.com> 
> Gesendet: Donnerstag, 13. August 2020 01:30
> An: benjamin.haendel@gmx.net; linux-btrfs@vger.kernel.org
> Betreff: Re: AW: Tree-checker Issue / Corrupt FS after upgrade ?
> 
> 
> 
> On 2020/8/13 上午7:10, benjamin.haendel@gmx.net wrote:
>> Hi Qu,
>>
>> thanks for your reply, i am not sure what to do from here on.
>> What do i have to download from here or compile/make/install etc. ?
> 
> You need to compile that branch.
> 
> For how to compile, please check the README.md.
> 
> 
>>
>> I'm no total idiot but i still don't understand what i have to get And 
>> how to apply it...sorry :(
> 
> Or you can use btrfs-send to send out the content of your fs with older kernel, and create a new fs using newer kernel, then receive the stream.
> 
> The uninitialized data is only in extent tree, which won't be sent with the stream, by receiving it with newer kernel, you won't lose anything.
> 
> Thanks,
> Qu
> 
>>
>> Best Regards,
>> Ben
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Qu Wenruo <quwenruo.btrfs@gmx.com>
>> Gesendet: Donnerstag, 13. August 2020 00:51
>> An: benjamin.haendel@gmx.net; linux-btrfs@vger.kernel.org
>> Betreff: Re: Tree-checker Issue / Corrupt FS after upgrade ?
>>
>>
>>
>> On 2020/8/13 上午12:58, benjamin.haendel@gmx.net wrote:
>>> Hi,
>>>
>>> i have been running my little Storage (32TB) on a Ubuntu 18.04 LTS 
>>> Machine with btrfs-progs 4.17. I then did my monthly upgrade (apt
>>> dist-upgrade) and after a reboot my Partition could not mount with the error message:
>>> "root@Userv:/home/benjamin# mount -r ro btrfs /dev/mapper/Crypto 
>>> /media/Storage
>>> mount: bad usage"
>>>
>>> I then proceeded to run a btrfs check which gave thousands of errors 
>>> and then also a super-recover:
>>> root@Userv:/home/benjamin# btrfs rescue super-recover -v 
>>> /dev/mapper/Crypto All Devices:
>>> Device: id = 1, name = /dev/mapper/Crypto
>>>
>>> Before Recovering:
>>> [All good supers]:
>>> device name = /dev/mapper/Crypto
>>> superblock bytenr = 65536
>>>
>>> device name = /dev/mapper/Crypto
>>> superblock bytenr = 67108864
>>>
>>> device name = /dev/mapper/Crypto
>>> superblock bytenr = 274877906944
>>>
>>> [All bad supers]:
>>>
>>> All supers are valid, no need to recover
>>>
>>> I now checked my dmesg log:
>>> [45907.451840] BTRFS critical (device dm-0): corrupt leaf:
>>> block=22751711027200 slot=1 extent bytenr=6754755866624 len=4096 
>>> invalid generation, have 22795412619264 expect (0, 207589]
>>
>> This is caused by older kernel, which writes some uninitialized value onto disk.
>>
>> You can try to fix it with this branch:
>> https://github.com/adam900710/btrfs-progs/tree/extent_gen_repair
>>
>> Or you can use older kernel to delete the offending extents.
>>
>> Thanks,
>> Qu
>>
>>> [45907.451848] BTRFS error (device dm-0): block=22751711027200 read 
>>> time tree block corruption detected [45907.451892] BTRFS error 
>>> (device
>>> dm-0): failed to read block groups: -5 [45907.510712] BTRFS error 
>>> (device dm-0): open_ctree failed
>>>
>>> Google inquiries to this topic led me to this link:
>>> https://btrfs.wiki.kernel.org/index.php/Tree-checker
>>> It tells me to mail here first so thats what i am doing. I kind of 
>>> suspect since everything worked perfect (Memtest also no errors) 
>>> before the update, it has to do something with that update. I am 
>>> wondering if it would help if i deleted my OS Disk and reinstalled an 
>>> older Version of Ubuntu, like
>>> 16.04.6 LTS ?
>>>
>>> Since then i upgraded to 20.04 LTS with BTRFS-PROGS 5.7 as a lot of 
>>> forum entries said it would be wise to use the newer versions as older were buggy.
>>> That brought no help as well.
>>>
>>> Since i am no Linux/Unix Expert i thought it might be better to ask 
>>> now first as advised in the link above before proceeding with any other plans.
>>>
>>> I find it hard to believe that all data is gone, i feel its buggy 
>>> behavior as the partition and everything is still there:
>>> root@Userv:/home/benjamin# btrfs fi show
>>> Label: 'Storage'  uuid: 46c7d04a-d6ac-45be-94cc-724919faca2b
>>> Total devices 1 FS bytes used 28.23TiB
>>> devid    1 size 29.10TiB used 29.04TiB path /dev/mapper/Crypto
>>>
>>> Best Regards,
>>> Benjamin Händel
>>>
>>
>>
> 
> 


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

Re: AW: AW: AW: Tree-checker Issue / Corrupt FS after upgrade ?

[Qu Wenruo]

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



On 2020/8/15 上午3:05, benjamin.haendel@gmx.net wrote:
> Hi Qu,
> 
> i did all that and i have now again access to the Storage.

Btrfs check --repair log of that run please.
I guess you haven't keep it...

And "btrfs check" of current fs please.

> Sadly i am now encountering some errors and bugs and i thought
> You might want to know about that.
> 
> 1. I am missing some folders and files
> 2. Some folders are there but no files in them
> 3. i can only access the drive via the samba share - not on the server directly
> 4. In Windows it shows "28TB of usage" but when i mark all data and hit alt+enter it counts to 21.1 TB only

Windows? Why it's related to Windows then?
We're talking about btrfs, right?

For the total usage, it's completely sane as btrfs use extent booking,
which takes extra space.

Thanks,
Qu


> 
> I am unsure if that data is now lost forever or if ist just a bug or what exactly is the problem.
> Do you think i could still "btrfs send" the Data and it will all be back or are those files lost due to new enumeration by btrfs-check Repair ?
> 
> Best Regards,
> Ben
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Qu Wenruo <quwenruo.btrfs@gmx.com> 
> Gesendet: Freitag, 14. August 2020 02:57
> An: benjamin.haendel@gmx.net
> Cc: linux-btrfs@vger.kernel.org
> Betreff: Re: AW: AW: Tree-checker Issue / Corrupt FS after upgrade ?
> 
> 
> 
> On 2020/8/14 上午5:01, benjamin.haendel@gmx.net wrote:
>> Hi Qu,
>>
>> i downloaded the code, compiled and installed it.
> 
> You still need to run "btrfs check --repair".
> 
> Considering you haven't post that output, I guess you didn't run that.
> 
>> Still could not mount the FS with error:
>> mount: /media/Storage: wrong fs type, bad option, bad superblock on /dev/mapper/Crypto, missing codepage or helper program, or other error.
>>
>> Dmesg is telling me:
>> [  174.061205] Btrfs loaded, crc32c=crc32c-intel [  174.081002] BTRFS: 
>> device label Storage devid 1 transid 207602 /dev/dm-0 [  192.175157] 
>> BTRFS info (device dm-0): disk space caching is enabled [  204.025699] 
>> BTRFS critical (device dm-0): corrupt leaf: block=22751711027200 
>> slot=1 extent bytenr=6754755866624 len=4096 invalid generation, have 
>> 22795412619264 expect (0, 207603] [  204.025703] BTRFS error (device 
>> dm-0): block=22751711027200 read time tree block corruption detected [  
>> 204.025731] BTRFS error (device dm-0): failed to read block groups: -5 
>> [  204.076709] BTRFS error (device dm-0): open_ctree failed
>>
>> I am unsure of what to do now. Did i have to run a btrfs check --repair with the compiled btrfs branch ?
> 
> Yes.
> 
>> I also removed all other versions of btrfs now to see if an old version could read it, it now says:
>> root@Userv:~# btrfs --version
>> btrfs-progs v4.1
> 
> Nope, you're not using the correct version.
> 
>>
>> Still i can not mount the drive. How can i at least get read access to my data ?
> 
> Just go using your older kernel, and wait for your distro to provide newer enough btrfs-progs.
> 
> Thanks,
> Qu
> 
>>
>> Best Regards,
>> Ben
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Qu Wenruo <quwenruo.btrfs@gmx.com>
>> Gesendet: Donnerstag, 13. August 2020 01:30
>> An: benjamin.haendel@gmx.net; linux-btrfs@vger.kernel.org
>> Betreff: Re: AW: Tree-checker Issue / Corrupt FS after upgrade ?
>>
>>
>>
>> On 2020/8/13 上午7:10, benjamin.haendel@gmx.net wrote:
>>> Hi Qu,
>>>
>>> thanks for your reply, i am not sure what to do from here on.
>>> What do i have to download from here or compile/make/install etc. ?
>>
>> You need to compile that branch.
>>
>> For how to compile, please check the README.md.
>>
>>
>>>
>>> I'm no total idiot but i still don't understand what i have to get 
>>> And how to apply it...sorry :(
>>
>> Or you can use btrfs-send to send out the content of your fs with older kernel, and create a new fs using newer kernel, then receive the stream.
>>
>> The uninitialized data is only in extent tree, which won't be sent with the stream, by receiving it with newer kernel, you won't lose anything.
>>
>> Thanks,
>> Qu
>>
>>>
>>> Best Regards,
>>> Ben
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Qu Wenruo <quwenruo.btrfs@gmx.com>
>>> Gesendet: Donnerstag, 13. August 2020 00:51
>>> An: benjamin.haendel@gmx.net; linux-btrfs@vger.kernel.org
>>> Betreff: Re: Tree-checker Issue / Corrupt FS after upgrade ?
>>>
>>>
>>>
>>> On 2020/8/13 上午12:58, benjamin.haendel@gmx.net wrote:
>>>> Hi,
>>>>
>>>> i have been running my little Storage (32TB) on a Ubuntu 18.04 LTS 
>>>> Machine with btrfs-progs 4.17. I then did my monthly upgrade (apt
>>>> dist-upgrade) and after a reboot my Partition could not mount with the error message:
>>>> "root@Userv:/home/benjamin# mount -r ro btrfs /dev/mapper/Crypto 
>>>> /media/Storage
>>>> mount: bad usage"
>>>>
>>>> I then proceeded to run a btrfs check which gave thousands of errors 
>>>> and then also a super-recover:
>>>> root@Userv:/home/benjamin# btrfs rescue super-recover -v 
>>>> /dev/mapper/Crypto All Devices:
>>>> Device: id = 1, name = /dev/mapper/Crypto
>>>>
>>>> Before Recovering:
>>>> [All good supers]:
>>>> device name = /dev/mapper/Crypto
>>>> superblock bytenr = 65536
>>>>
>>>> device name = /dev/mapper/Crypto
>>>> superblock bytenr = 67108864
>>>>
>>>> device name = /dev/mapper/Crypto
>>>> superblock bytenr = 274877906944
>>>>
>>>> [All bad supers]:
>>>>
>>>> All supers are valid, no need to recover
>>>>
>>>> I now checked my dmesg log:
>>>> [45907.451840] BTRFS critical (device dm-0): corrupt leaf:
>>>> block=22751711027200 slot=1 extent bytenr=6754755866624 len=4096 
>>>> invalid generation, have 22795412619264 expect (0, 207589]
>>>
>>> This is caused by older kernel, which writes some uninitialized value onto disk.
>>>
>>> You can try to fix it with this branch:
>>> https://github.com/adam900710/btrfs-progs/tree/extent_gen_repair
>>>
>>> Or you can use older kernel to delete the offending extents.
>>>
>>> Thanks,
>>> Qu
>>>
>>>> [45907.451848] BTRFS error (device dm-0): block=22751711027200 read 
>>>> time tree block corruption detected [45907.451892] BTRFS error 
>>>> (device
>>>> dm-0): failed to read block groups: -5 [45907.510712] BTRFS error 
>>>> (device dm-0): open_ctree failed
>>>>
>>>> Google inquiries to this topic led me to this link:
>>>> https://btrfs.wiki.kernel.org/index.php/Tree-checker
>>>> It tells me to mail here first so thats what i am doing. I kind of 
>>>> suspect since everything worked perfect (Memtest also no errors) 
>>>> before the update, it has to do something with that update. I am 
>>>> wondering if it would help if i deleted my OS Disk and reinstalled 
>>>> an older Version of Ubuntu, like
>>>> 16.04.6 LTS ?
>>>>
>>>> Since then i upgraded to 20.04 LTS with BTRFS-PROGS 5.7 as a lot of 
>>>> forum entries said it would be wise to use the newer versions as older were buggy.
>>>> That brought no help as well.
>>>>
>>>> Since i am no Linux/Unix Expert i thought it might be better to ask 
>>>> now first as advised in the link above before proceeding with any other plans.
>>>>
>>>> I find it hard to believe that all data is gone, i feel its buggy 
>>>> behavior as the partition and everything is still there:
>>>> root@Userv:/home/benjamin# btrfs fi show
>>>> Label: 'Storage'  uuid: 46c7d04a-d6ac-45be-94cc-724919faca2b
>>>> Total devices 1 FS bytes used 28.23TiB
>>>> devid    1 size 29.10TiB used 29.04TiB path /dev/mapper/Crypto
>>>>
>>>> Best Regards,
>>>> Benjamin Händel
>>>>
>>>
>>>
>>
>>
> 
> 


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

Re: AW: AW: AW: Tree-checker Issue / Corrupt FS after upgrade ?

[Chris Murphy]

On Fri, Aug 14, 2020 at 5:06 PM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>
>
>
> On 2020/8/15 上午3:05, benjamin.haendel@gmx.net wrote:

> > 1. I am missing some folders and files
> > 2. Some folders are there but no files in them
> > 3. i can only access the drive via the samba share - not on the server directly
> > 4. In Windows it shows "28TB of usage" but when i mark all data and hit alt+enter it counts to 21.1 TB only
>
> Windows? Why it's related to Windows then?
> We're talking about btrfs, right?
>

Suggests the file system is being used with WinBtrfs.

https://github.com/maharmstone/btrfs


-- 
Chris Murphy

Re: Tree-checker Issue / Corrupt FS after upgrade ?

[Roman Mamedov]

On Sun, 16 Aug 2020 20:25:20 -0600
Chris Murphy <lists@colorremedies.com> wrote:

> On Fri, Aug 14, 2020 at 5:06 PM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
> >
> > On 2020/8/15 上午3:05, benjamin.haendel@gmx.net wrote:
> 
> > > 1. I am missing some folders and files
> > > 2. Some folders are there but no files in them
> > > 3. i can only access the drive via the samba share - not on the server directly
> > > 4. In Windows it shows "28TB of usage" but when i mark all data and hit alt+enter it counts to 21.1 TB only
> >
> > Windows? Why it's related to Windows then?
> > We're talking about btrfs, right?
> >
> 
> Suggests the file system is being used with WinBtrfs.
> 
> https://github.com/maharmstone/btrfs

Or just accessed via network from a Windows client, as hinted in point #3
about a Samba share.

But as for why behavior described in point #3 would be the case, no idea, that
sounds like something that's not really possible.

One possibility though is that a file manager that the user runs on the server
itself bails on showing a directory listing entirely, if it has some incorrect
entries in it (those that show up as ???????????? in 'ls'), but the Windows
one doesn't, or Samba doesn't export those in the first place. I'd suggest
examining the drive content from console with "ls" and not via any graphical
or even text-based file manager.

-- 
With respect,
Roman