From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Btrfs on a failing drive
Date: Wed, 19 Nov 2014 03:06:45 +0000 (UTC) [thread overview]
Message-ID: <pan$4d12d$ac36086c$dc5d83e5$8040fa67@cox.net> (raw)
In-Reply-To: 546B676E.6040305@ubuntu.com
Phillip Susi posted on Tue, 18 Nov 2014 10:36:14 -0500 as excerpted:
> As I said before though, the errors you posted from dmesg don't indicate
> that the drive failed to read sectors, but rather that it returned
> incorrect data, and this is *NEVER* supposed to happen.
>
> I'd suggest running a few passes of badblocks over the drive, testing
> writing different patterns and verifying that they read back correctly.
+1 for badblocks! =:^)
Tho a hint if you decide to test multiple drives as I did some years
ago. Doing a multiple passes (I'd suggest at least two) on a full drive
can take QUITE some time (days), due to the shear volume of data to be
written to the drive, then read back to verify, then written as a new
pattern and read back again.
But unlike IDE, the bottleneck on at least spinning rust SATA (well,
unless you go heavy port-multiplier) tends to be the platters themselves,
not the buses as they're point-to-point now days, or the controllers.
Generally you can process four or more drives in parallel without slowing
down the individual results significantly at all. Thus, while it takes
days to test a single drive, it normally takes the same time to process
four drives in parallel! So if you have 4+ devices to badblocks-test,
definitely setup four (perhaps more, depending on hardware layout)
instances of badblocks running at once, one to each of the devices. Cut
your time for all four done serially to say 8 days, to only two days when
done in parallel! =:^)
Of course good SSDs tend to be both many times faster and several times
smaller in capacity, so a badblocks run on them should be MUCH faster,
perhaps a couple hours vs a couple days, and much less parallelizable
without slowing all of them down, since they tend to saturate the bus or
close to it (the reason fast SATA-based SSDs all tend to rate similarly
speed-wise, the SATA bus is the bottleneck and the PCI-E bus isn't /that/
far behind!, tho the PCIE bus can be /enough/ faster to give direct PCIE-
interface SSDs a definite speed boost over top-of-the-line SATA interface
devices... for those that can afford their accordingly higher prices).
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2014-11-19 3:06 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-17 22:55 Btrfs on a failing drive Fennec Fox
2014-11-18 1:17 ` Phillip Susi
[not found] ` <CAD1x5BDJhZ6a=91G8+UzLTY+Oik7MVpr-XGKOQrOnXpkRLjwug@mail.gmail.com>
2014-11-18 15:36 ` Phillip Susi
2014-11-19 3:06 ` Duncan [this message]
[not found] ` <CAD1x5BDDrKoJ2Zf6Tf5MK4VBc3Q57jPaF43KOdhgcmw7uCK=Zg@mail.gmail.com>
2014-11-19 18:19 ` Phillip Susi
2014-11-18 6:10 ` Chris Murphy
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='pan$4d12d$ac36086c$dc5d83e5$8040fa67@cox.net' \
--to=1i5t5.duncan@cox.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