From: Phillip Susi <psusi@ubuntu.com>
To: Fennec Fox <fennectech@gmail.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Btrfs on a failing drive
Date: Tue, 18 Nov 2014 10:36:14 -0500 [thread overview]
Message-ID: <546B676E.6040305@ubuntu.com> (raw)
In-Reply-To: <CAD1x5BDJhZ6a=91G8+UzLTY+Oik7MVpr-XGKOQrOnXpkRLjwug@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Please get in the habit of using your mail client's reply-to-all
button instead of reply; there is no need for us to take this
conversation private.
On 11/17/2014 10:15 PM, Fennec Fox wrote:
<snip big smartctl output>
> i know the drive is dying and needs replacing but i need to keep
> this drive arround for some time longer as i cant run from a 32
> gb usb far too slow
If it were just a few bad sectors, then you could deal with that by
writing to them, which would force the drive to reallocate them from
the spare pool. I'd suggest you dd /dev/zero all over the drive so
everything is written to, then check the smart stats again. If there
were no write errors, and the smart stats show zero pending sectors,
then everything has been reallocated and you should be ok to reformat
the drive and use it.
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. If it can't do that, then there's nothing for it but to
junk the drive.
badblocks -b 4096 -c 256 -s -t 00 /dev/sda
That will read the drive and verify that it is full of zeros. If that
passes, write a different pattern to the disk and verify that reads
back correctly:
badblocks -b 4096 -c 256 -s -w /dev/sda
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
iQEcBAEBAgAGBQJUa2duAAoJEI5FoCIzSKrw+0AIAJNAqF1rY2m5Oalehr3dz+G4
O6h9XERRiTl8GVMgcj7ZybeP3sFroItgiki5UdhRsjNoPEPRQpv3hApY7p2cEUtk
yNn8jAeRBjA0kli+5HMHY3eHL4RmLO3mrLmNoAu5HShvWBE4zj/18vvk15m/u5rj
SnrxBUSQ91V0D6p/CFkjAX9iBZBoWx4+J7Wz8EOhqnFJbqXaCEOdj7NKrjQ/7r+Q
5gxQWD4x54NQSGPfexERtRRaL9drE3JoLTbOEC+xdt7a9MwHw5Z50DTfMRzibpFP
kdKlRCLMzcNGXSVt/187MMbpvROXBWhfmAAFOCz5rGtrGjX3V6+/7hpPBn5ft3E=
=L5No
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2014-11-18 15:36 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 [this message]
2014-11-19 3:06 ` Duncan
[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=546B676E.6040305@ubuntu.com \
--to=psusi@ubuntu.com \
--cc=fennectech@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox