Linux Btrfs filesystem development
 help / color / mirror / Atom feed
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


  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