linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Robin Bowes <robin-lists@robinbowes.com>
To: linux-raid@vger.kernel.org
Subject: Re: Joys of spare disks!
Date: Wed, 02 Mar 2005 02:48:32 +0000	[thread overview]
Message-ID: <d03987$nif$1@sea.gmane.org> (raw)
In-Reply-To: <cvv9ai$svg$1@sea.gmane.org>

Robin Bowes wrote:
> Hi,
> 
> I run a RAID5 array built from six 250GB Maxtor Maxline II SATA disks. 
> After having several problems with Maxtor disks I decided to use a spare 
> disk, i.e. 5+1 spare.
> 
> Well, *another* disk failed last week. The spare disk was brought into 
> play seamlessly:

Thanks to some advice from Guy the "failed" disk is now back up and running.

To fix it I did the following;

Removed the bad partition from the array:

   mdadm --manage /dev/md5 --remove /dev/sdd2

Wrote to the whole disk, causing bad blocks to be re-located:

   [root@dude test]#  dd if=/dev/zero of=/dev/sdd2 bs=64k
   dd: writing `/dev/sdd2': No space left on device
   3806903+0 records in
   3806902+0 records out

Verified the disk:

   [root@dude test]# dd if=/dev/sdd2 of=/dev/null bs=64k
   3806902+1 records in
   3806902+1 records out

Added the partition back to the array:

   [root@dude test]# mdadm /dev/md5 --add /dev/sdd2
   mdadm: hot added /dev/sdd2

Quick look at the arrya configuration to make sure:

   [root@dude test]# mdadm --detail /dev/md5
   /dev/md5:
            Version : 00.90.01
      Creation Time : Thu Jul 29 21:41:38 2004
         Raid Level : raid5
         Array Size : 974566400 (929.42 GiB 997.96 GB)
        Device Size : 243641600 (232.35 GiB 249.49 GB)
       Raid Devices : 5
      Total Devices : 6
    Preferred Minor : 5
        Persistence : Superblock is persistent

        Update Time : Wed Mar  2 02:01:24 2005
              State : clean
     Active Devices : 5
    Working Devices : 6
     Failed Devices : 0
      Spare Devices : 1

             Layout : left-symmetric
         Chunk Size : 128K

               UUID : a4bbcd09:5e178c5b:3bf8bd45:8c31d2a1
             Events : 0.7036368

        Number   Major   Minor   RaidDevice State
           0       8        2        0      active sync   /dev/sda2
           1       8       18        1      active sync   /dev/sdb2
           2       8       34        2      active sync   /dev/sdc2
           3       8       82        3      active sync   /dev/sdf2
           4       8       66        4      active sync   /dev/sde2

           5       8       50        -      spare   /dev/sdd2

This raises the question: why can't md do this automatically? Not for 
the whole disk/partition, but just for a bad block when encountered? I 
envisage something like:

md attempts read
one disk/partition fails with a bad block
md re-calculates correct data from other disks
md writes correct data to "bad" disk
  - disk will re-locate the bad block

Of course, if you encounter further bad blocks when reading from the 
other disks then you're screwed and it's time to get the backup tapes out!

Is there any sound reason why this is not feasible? Is it just that 
someone needs to write the code to implement it?

R.
-- 
http://robinbowes.com


  parent reply	other threads:[~2005-03-02  2:48 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-28 14:24 Joys of spare disks! Robin Bowes
2005-02-28 15:04 ` Jon Lewis
2005-02-28 15:23   ` Robin Bowes
2005-02-28 15:54     ` Nicola Fankhauser
2005-02-28 17:04       ` Robin Bowes
2005-02-28 18:58         ` Nicola Fankhauser
2005-02-28 19:25           ` Robin Bowes
2005-03-02  2:48 ` Robin Bowes [this message]
2005-03-02  2:59   ` Neil Brown
2005-03-02  3:50   ` Molle Bestefich
2005-03-02  3:52     ` Molle Bestefich
2005-03-02  5:52     ` Guy
2005-03-02 12:05       ` Molle Bestefich
2005-03-02 16:16         ` Guy
2005-03-03  9:37           ` Molle Bestefich
2005-03-02  4:57   ` Brad Campbell
2005-03-02  5:53     ` Guy
     [not found]       ` <eaa6dfe0503080915276466a1@mail.gmail.com>
2005-03-08 17:15         ` Derek Piper
     [not found]         ` <200503091704.j29H4l517152@www.watkins-home.com>
2005-03-10 19:24           ` Derek Piper
  -- strict thread matches above, loose matches on Subject: below --
2005-03-07 16:36 LinuxRaid
2005-03-07 17:09 ` Peter T. Breuer
2005-03-07 20:15 LinuxRaid

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='d03987$nif$1@sea.gmane.org' \
    --to=robin-lists@robinbowes.com \
    --cc=linux-raid@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;
as well as URLs for NNTP newsgroup(s).