All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Murphy <lists@colorremedies.com>
To: Btrfs BTRFS <linux-btrfs@vger.kernel.org>,
	Qu Wenruo <quwenruo.btrfs@gmx.com>
Subject: feedback on three different scrub methods
Date: Mon, 6 Nov 2017 13:17:48 -0700	[thread overview]
Message-ID: <CAJCQCtTsfNgSBDdnq0uFd1ZRRY0AWbv=rx5X1UUGp1i9hK-4hw@mail.gmail.com> (raw)

I just did scrubs on five different volumes using all three scrub
methods. There were no errors found, so the test leaves uncertain what
the error handling differences are between the three scrubs. But at
the least with no errors, there are also no disagreements between the
three methods.

1. Speed. Both normal online scrub and the btrfsck --check-data-csum
methods, I get ~275MB/s transfers per iotop. Whereas with --offline
scrub I'm seeing 60%-67% of that, or ~170MB/s transfers. That's
substantially slower. If it were using less CPU or the system more
responsive, it might be worth that trade off in time. But the CPU %
and system responsiveness for other tasks seemed the same, it just
took longer.

2. Each method reports different statistics in different formats. And
that's fine except I can't make heads or tails out of the information
presented, making it basically useless at least to this user.

[chris@f26s ~]$ sudo /srv/scratch/gitsworking/btrfs-progs/btrfs check
--check-data-csum /dev/mapper/sdd
Checking filesystem on /dev/mapper/sdd
UUID: f5adc913-bbea-4340-8b5f-3411e2cda642
checking extents
checking free space cache
checking fs roots
checking csums
checking root refs
found 601877024768 bytes used, no error found
total csum bytes: 586444884
total tree bytes: 1208827904
total fs tree bytes: 510672896
total extent tree bytes: 53755904
btree space waste bytes: 142065358
file data blocks allocated: 2213492944896
 referenced 1977848909824


[chris@f26s ~]$ sudo btrfs-progs/btrfs scrub start --offline
/dev/mapper/sdd
[sudo] password for chris:
Scrub result:
Tree bytes scrubbed: 2417655808
Tree extents scrubbed: 295124
Data bytes scrubbed: 2398080548864
Data extents scrubbed: 751158
Data bytes without csum: 297271296
Read error: 0
Verify error: 0
Csum error: 0

I'm not finding any way these add up. Seems like --offline's tree
bytes scrubbed + data bytes scrubbed should add up to
--check-data-csum's found bytes - waste bytes? But no, I have no idea
what I'm looking at or how it's useful to the user, but OK.


I used kernel 4.13.10 and btrfs-progs 4.13.3 for the usual 'btrfs
scrub start' and the less common 'btrfs check ----check-data-csum'
methods; and Qu's v4.11.1-89-gf939adf2 with offline_scrub checked out.




-- 
Chris Murphy

             reply	other threads:[~2017-11-06 20:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-06 20:17 Chris Murphy [this message]
2017-11-07  0:54 ` feedback on three different scrub methods Qu Wenruo
2017-11-07  8:45   ` Nikolay Borisov
2017-11-07  8:58     ` 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='CAJCQCtTsfNgSBDdnq0uFd1ZRRY0AWbv=rx5X1UUGp1i9hK-4hw@mail.gmail.com' \
    --to=lists@colorremedies.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.com \
    /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.