linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephan Olbrich <stephanolbrich@gmx.de>
To: linux-btrfs@vger.kernel.org
Subject: Re: bad tree block start, want 705757184 have 82362368
Date: Sun, 18 Nov 2018 08:56:06 +0100	[thread overview]
Message-ID: <32822632.LIG5tvG1AF@chaos-desktop> (raw)
In-Reply-To: <e65c8b2a-e337-6c9c-6fbc-839d810353df@gmx.com>

Am Sonntag, 18. November 2018, 01:30:14 CET schrieb Qu Wenruo:
> >>> Late on I got the same errors for my /home partition (on the same drive)
> >>> as well. I have snapshots of all partitions on another drive made by
> >>> btrbk. To get a working system, I made new (rw) snapshots of the most
> >>> recent backup and setup grub and fstab, so my system would boot from the
> >>> other drive. Unfortunately now I got the "bad tree block start" error
> >>> again at least once in dmesg but I didn't save it and it's not in syslog
> >>> :-( What I remember is, that it was followed by other btrfs error
> >>> messages saying something about correcting something. And the filesystem
> >>> was still read/write this time.
> >>> At the moment I can't reproduce it.

Today it happend again (sdb is my backup drive, which is my main drive at the moment):
[  286.325857] BTRFS error (device sdb1): bad tree block start, want 787719208960 have 11268016545161247416
[  286.363245] BTRFS info (device sdb1): read error corrected: ino 0 off 787719208960 (dev /dev/sdb1 sector 1243815072)
[  286.364087] BTRFS info (device sdb1): read error corrected: ino 0 off 787719213056 (dev /dev/sdb1 sector 1243815080)
[  286.425946] BTRFS info (device sdb1): read error corrected: ino 0 off 787719217152 (dev /dev/sdb1 sector 1243815088)
[  286.427530] BTRFS info (device sdb1): read error corrected: ino 0 off 787719221248 (dev /dev/sdb1 sector 1243815096)


> >>> Is there any way to find out, which files are affected by the errors
> >>> above?
> >> 
> >> No files are affected, but an essential tree, extent tree, is corrupted.
> >> 
> >> Normally this may prevent RW mount, and even it mounts it can still
> >> cause problem when doing any write.
> >> It could even prevent RO mount if the corrupted leaf contains block
> >> group item.
> >> 
> >> But your data should be OK if there is no other corruption, and in that
> >> case btrfs-restore should work well.
> >> 
> >>> I don't really trust the data on the drive I'm using at the
> >>> moment, as it has shown errors as well, but I have a less current backup
> >>> on yet another drive but at it is a few weeks old, I don't want to use
> >>> it
> >>> to setup the system on the SSD again, but just copy the relevant files
> >>> if
> >>> possible. Or is it possible to repair the original file system?
> >> 
> >> At least we need "btrfs check" output.
> > 
> > I updated btrfs-progs and run btrfs check for / and /home
> > No errors are found on / (sda2), but there are errors on /home ??
> > 
> > $ btrfs --version
> > btrfs-progs v4.19
> > 
> > $ btrfs check /dev/sda2
> > Opening filesystem to check...
> > Checking filesystem on /dev/sda2
> > UUID: 80368989-ffa8-463c-98fb-fe2e28ca7bf3
> > [1/7] checking root items
> > [2/7] checking extents
> > [3/7] checking free space cache
> > [4/7] checking fs roots
> > [5/7] checking only csums items (without verifying data)
> > [6/7] checking root refs
> > [7/7] checking quota groups skipped (not enabled on this FS)
> > found 64816218112 bytes used, no error found
> > total csum bytes: 59518732
> > total tree bytes: 2180268032
> > total fs tree bytes: 1965965312
> > total extent tree bytes: 123289600
> > btree space waste bytes: 478665777
> > file data blocks allocated: 151083261952
> > 
> >  referenced 76879990784
> 
> This fs is completely fine, including your data.
> 
> > $ btrfs check /dev/sda4
> > Opening filesystem to check...
> > Checking filesystem on /dev/sda4
> > UUID: 81c38df8-b7f9-412c-8c88-cfde8db68eb1
> > [1/7] checking root items
> > [2/7] checking extents
> > [3/7] checking free space cache
> > [4/7] checking fs roots
> > root 257 inode 7970563 errors 100, file extent discount
> > 
> > Found file extent holes:
> >         start: 0, len: 20480
> > 
> > root 257 inode 7970564 errors 100, file extent discount
> > 
> > Found file extent holes:
> >         start: 0, len: 77824
> > 
> > ERROR: errors found in fs roots
> 
> These are just minor errors, won't even causing any data mismatch.
> 
> So all your fses should be mostly OK.
> 
> Would you please try to use v4.19-rc* to see if it changes anything?
v4.19-rc1 is the only rc I found, but that is older than v4.19, right?
Anyway, here is the output:

$ btrfs --version
btrfs-progs v4.19-rc1

$ btrfs check /dev/sda2
Opening filesystem to check...
Checking filesystem on /dev/sda2
UUID: 80368989-ffa8-463c-98fb-fe2e28ca7bf3
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
[5/7] checking only csums items (without verifying data)
[6/7] checking root refs
[7/7] checking quota groups skipped (not enabled on this FS)
found 64816218112 bytes used, no error found
total csum bytes: 59518732
total tree bytes: 2180268032
total fs tree bytes: 1965965312
total extent tree bytes: 123289600
btree space waste bytes: 478665777
file data blocks allocated: 151083261952
 referenced 76879990784

$ btrfs check /dev/sda4
Opening filesystem to check...
Checking filesystem on /dev/sda4
UUID: 81c38df8-b7f9-412c-8c88-cfde8db68eb1
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
root 257 inode 7970563 errors 100, file extent discount
Found file extent holes:
        start: 0, len: 20480
root 257 inode 7970564 errors 100, file extent discount
Found file extent holes:
        start: 0, len: 77824
ERROR: errors found in fs roots
found 303386652672 bytes used, error(s) found
total csum bytes: 289501272
total tree bytes: 2336227328
total fs tree bytes: 1766473728
total extent tree bytes: 202014720                                                                                                                                                                        
btree space waste bytes: 519245278                                                                                                                                                                        
file data blocks allocated: 6851730792448                                                                                                                                                                 
 referenced 533348069376


Thanks,
Stephan


> Thanks,
> Qu
> 
> > found 303386652672 bytes used, error(s) found
> > total csum bytes: 289501272
> > total tree bytes: 2336227328
> > total fs tree bytes: 1766473728
> > total extent tree bytes: 202014720
> > btree space waste bytes: 519245278
> > file data blocks allocated: 6851730792448
> > 
> >  referenced 533348069376
> > 
> > Thanks,
> > Stephan
> > 
> >>> Some information about my system:
> >>> Kubuntu 18.04
> >>> Kernel 4.19.1 when the problem occured, now 4.19.2
> >>> btrfs-tools 4.15.1
> >> 
> >> And "btrfs check" should be executed using latest version.
> >> 
> >> Thanks,
> >> Qu
> >> 
> >>> Regards,
> >>> Stephan





  reply	other threads:[~2018-11-18  7:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-16 16:17 bad tree block start, want 705757184 have 82362368 Stephan Olbrich
2018-11-16 16:44 ` Nikolay Borisov
2018-11-17 20:34   ` Stephan Olbrich
2018-11-17  8:03 ` Qu Wenruo
2018-11-17 20:28   ` Stephan Olbrich
2018-11-18  0:30     ` Qu Wenruo
2018-11-18  7:56       ` Stephan Olbrich [this message]
2018-11-18 13:31         ` Anand Jain
2018-11-19 19:42           ` Stephan Olbrich

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=32822632.LIG5tvG1AF@chaos-desktop \
    --to=stephanolbrich@gmx.de \
    --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;
as well as URLs for NNTP newsgroup(s).