linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Robin Hill <robin@robinhill.me.uk>
To: linux-raid@vger.kernel.org
Subject: Re: RAID5 made with assume-clean
Date: Wed, 6 Feb 2013 13:02:54 +0000	[thread overview]
Message-ID: <20130206130254.GA12118@cthulhu.home.robinhill.me.uk> (raw)
In-Reply-To: <20130206115258.GA31466@animx.eu.org>

[-- Attachment #1: Type: text/plain, Size: 2152 bytes --]

On Wed Feb 06, 2013 at 06:52:58AM -0500, Wakko Warner wrote:

> I was testing different parameters with --assume-clean to avoid the initial
> rebuild.  When I decided on the parameters I wanted, I forgot to create the
> array without --assume-clean.  I have 3 disks in the array.
> 
> I thought that I'd run a check on it by doing
> echo check > /sys/block/md0/md/sync_action
> 
> /proc/mdstat is showing this:
> Personalities : [raid1] [raid6] [raid5] [raid4] 
> md0 : active raid5 sda1[0] sdb1[1] sdc1[2]
>       488018688 blocks super 1.1 level 5, 64k chunk, algorithm 2 [3/3] [UUU]
>       [============>........]  check = 61.7% (150688512/244009344) finish=7.1min speed=216592K/sec
> 
> unused devices: <none>
> 
> The thing is, the drives can only do ~60mb/sec and there is no disk
> activity.  The activity lights are not lit at all.  What would cause that?
> 
What disks are they? I would expect a modern SATA disk to be able to
handle 120MB/s for sequential read, so 220 across the array would be
pretty normal.

> I was also wondering if the raid5 did RMW on the parity with 3 disks when
> the array is written to.
> 
Not sure what the logic is on this. For a 3 disk array it'd need a
single read and 2 writes for a single chunk, whether it's doing RMW or
not. It will probably still do RMW though, as that avoids the
complication of special-casing things. I've had a quick look at the code
and I can't see any special casing (other than for a 2 disk array, where
the same data is written to both).

> I can rebuild the array without assume-clean if that's the only way I can
> get the parity to be correct, but I'd like to avoid doing that if possible.
> 
That's definitely the safest option. If you can verify the data then you
could run a repair and a fsck before verifying/restoring the data, but
that'd take far longer than a simple rebuild and restore.

HTH,
    Robin
-- 
     ___        
    ( ' }     |       Robin Hill        <robin@robinhill.me.uk> |
   / / )      | Little Jim says ....                            |
  // !!       |      "He fallen in de water !!"                 |

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2013-02-06 13:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-06 11:52 RAID5 made with assume-clean Wakko Warner
2013-02-06 13:02 ` Robin Hill [this message]
2013-02-06 14:54   ` Wakko Warner
2013-02-07 14:29     ` Robin Hill
2013-02-07 18:14       ` Wakko Warner

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=20130206130254.GA12118@cthulhu.home.robinhill.me.uk \
    --to=robin@robinhill.me.uk \
    --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).