public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: benjamin.haendel@gmx.net,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: AW: Tree-checker Issue / Corrupt FS after upgrade ?
Date: Thu, 13 Aug 2020 07:29:40 +0800	[thread overview]
Message-ID: <940c43d7-b7e0-82fa-d5a5-b81e672b85a9@gmx.com> (raw)
In-Reply-To: <000801d670fd$bb2f62d0$318e2870$@gmx.net>


[-- 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 --]

  parent reply	other threads:[~2020-08-12 23:29 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-12 16:58 Tree-checker Issue / Corrupt FS after upgrade ? benjamin.haendel
2020-08-12 22:50 ` Qu Wenruo
     [not found]   ` <000801d670fd$bb2f62d0$318e2870$@gmx.net>
2020-08-12 23:29     ` Qu Wenruo [this message]
     [not found]       ` <003301d671a8$b93b8b60$2bb2a220$@gmx.net>
2020-08-14  0:46         ` AW: AW: " Qu Wenruo
     [not found]       ` <000301d671b4$fc4a0650$f4de12f0$@gmx.net>
2020-08-14  0:56         ` Qu Wenruo
     [not found]           ` <003301d6726d$de5cbe30$9b163a90$@gmx.net>
2020-08-14 23:06             ` AW: " Qu Wenruo
2020-08-17  2:25               ` Chris Murphy
2020-08-17  6:40                 ` Roman Mamedov
     [not found] <000301d672d7$263c00d0$72b40270$@gmx.net>
2020-08-15  7:53 ` AW: " Qu Wenruo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=940c43d7-b7e0-82fa-d5a5-b81e672b85a9@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=benjamin.haendel@gmx.net \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox