All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Dave T <davestechshop@gmail.com>,
	Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: bad file extent, some csum missing - how to check that restored volumes are error-free?
Date: Thu, 15 Jul 2021 06:51:49 +0800	[thread overview]
Message-ID: <3be8bba9-60cd-2cce-a05d-6c24b8895f3f@gmx.com> (raw)
In-Reply-To: <CAGdWbB6qxBtVc1XtSF_wOR3NyR9nGpr5_Nc5RCLGT5NK=C4iRA@mail.gmail.com>



On 2021/7/15 上午1:53, Dave T wrote:
> I was running btrfs send | receive to a target host via ssh and the
> operation suddenly failed in the middle.
>
> I ran this check:
>
> btrfs check /dev/mapper/${xyz}
>
> This shows lots of these errors:
>    root 329 inode 262 errors 1040, bad file extent, some csum missing

Normally this is a minor error, normally caused by older kernels.

The original mode did a very bad report format.

You may want to run "btrfs check --mode=lowmem" to get a more human
readable report.
 From that we can get a full view of the problem and give better advice.

Thanks,
Qu

>    root 329 inode 7070 errors 1040, bad file extent, some csum missing
>    root 329 inode 7242 errors 1040, bad file extent, some csum missing
>    root 329 inode 7246 errors 1040, bad file extent, some csum missing
>    root 329 inode 7252 errors 1040, bad file extent, some csum missing
>    root 329 inode 7401 errors 1040, bad file extent, some csum missing
>    root 329 inode 7753 errors 1040, bad file extent, some csum missing
>    root 330 inode 588 errors 1040, bad file extent, some csum missing
>    root 334 inode 258 errors 1040, bad file extent, some csum missing
>    root 334 inode 636 errors 1040, bad file extent, some csum missing
>    root 334 inode 3151 errors 1040, bad file extent, some csum missing
>    ...
>    root 334 inode 184871 errors 1040, bad file extent, some csum missing
>    root 334 inode 184872 errors 1040, bad file extent, some csum missing
>    root 334 inode 184874 errors 1040, bad file extent, some csum missing
>
> I rebooted without any problems, then connected an external USB HDD.
> Then I created new snapshots and used btrfs send | receive to send
> them to the USB HDD.
>
> Next I installed a new SSD and restored the snapshots. Then I ran
> "btrfs check --check-data-csum /dev/mapper/abc" on the new device. It
> shows:
>
> Opening filesystem to check...
> Checking filesystem on /dev/mapper/abc
> UUID: fac54a70-8c27-4cbe-a8d0-325e761ba01d
> [1/7] checking root items
> [2/7] checking extents
> [3/7] checking free space cache
> [4/7] checking fs roots
> [5/7] checking csums against data
> [6/7] checking root refs
> [7/7] checking quota groups skipped (not enabled on this FS)
> found 128390598656 bytes used, no error found
> total csum bytes: 124046564
> total tree bytes: 1335197696
> total fs tree bytes: 1140211712
> total extent tree bytes: 50757632
> btree space waste bytes: 168388261
> file data blocks allocated: 127058169856
>   referenced 142833545216
>
> What else can or should I do to be sure my restored snapshots are error-free?
> What additional checks would you recommend on the new device?
> The new device is a Samsung EVO 970 Plus.
> The old device was a Samsung 950 Pro.
>

  reply	other threads:[~2021-07-14 22:51 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-14 17:53 bad file extent, some csum missing - how to check that restored volumes are error-free? Dave T
2021-07-14 22:51 ` Qu Wenruo [this message]
     [not found]   ` <CAGdWbB44nH7dgdP3qO_bFYZwbkrW37OwFEVTE2Bn+rn4d7zWiQ@mail.gmail.com>
     [not found]     ` <43e7dc04-c862-fff1-45af-fd779206d71c@gmx.com>
     [not found]       ` <CAGdWbB7Q98tSbPgHUBF+yjqYRBPZ-a42hd=xLwMZUMO46gfd0A@mail.gmail.com>
2021-07-15 22:19         ` Dave T
2021-07-15 22:30           ` Qu Wenruo
2021-07-15 22:49             ` Dave T
2021-07-16  1:05               ` Qu Wenruo
2021-07-16  2:32                 ` Qu Wenruo
2021-07-16 13:15                 ` Dave T
2021-07-16 13:28                   ` Qu Wenruo
2021-07-16 15:40                     ` Dave T
2021-07-16 23:06                       ` Qu Wenruo
2021-07-17  0:18                         ` Dave T
2021-07-17  0:25                           ` Qu Wenruo
2021-07-17  0:57                             ` Dave T
2021-07-17  0:59                               ` Qu Wenruo
2021-07-25 17:34                                 ` Dave T
2021-07-25 23:51                                   ` 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=3be8bba9-60cd-2cce-a05d-6c24b8895f3f@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=davestechshop@gmail.com \
    --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 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.