All of lore.kernel.org
 help / color / mirror / Atom feed
From: MRK <mrk@shiftmail.org>
To: Jeremy Sanders <jeremy@jeremysanders.net>
Cc: linux-raid@vger.kernel.org
Subject: Re: stuck tasks
Date: Mon, 12 Apr 2010 14:49:48 +0200	[thread overview]
Message-ID: <4BC316EC.9040808@shiftmail.org> (raw)
In-Reply-To: <hpuvbb$13t$1@dough.gmane.org>

On 04/12/2010 01:14 PM, Jeremy Sanders wrote:
> MRK wrote:
>
>    
>> You need to lower the sync speed by catting a value into
>> /sys/block/md{n}/md/sync_speed_max
>> the value should be about 1/3 lower than the max speed you see (cat
>> /proc/mdstat) now that it's not yet limited.
>> Set up a script to set it at boot.
>>      
> Thanks - I'll try it. It didn't happen in a raid sync, just during an rsync
> run. Would this have any effect on normal operation?
>    

!?!!

Mistake of mine, but I might have gotten the right answer by chance
I had read resyncing but you wrote rsyncing.
But you were in fact also resyncing from what you write below:


>> If it was not happening for you on older kernels might be a good sign:
>> it might mean that the resync is faster now...
>>
>> What is the sync speed you see (cat /proc/mdstat)? How many drives do
>> you have and what type of raid is that?
>>      
> We're only getting 30MB/s. I thought it used to be quite a lot faster. It
> seems to slow down as the sync progresses:
>
> [root@xback2 ~]#  cat /proc/mdstat
> Personalities : [raid6] [raid5] [raid4]
> md0 : active raid5 sdb1[0] sdj1[10](S) sdk1[9] sdl1[8] sdi1[7] sdh1[6]
> sdg1[5] sdf1[4] sde1[3] sdd1[2] sdc1[1]
>        8788959360 blocks level 5, 32k chunk, algorithm 2 [10/10] [UUUUUUUUUU]
>        [>....................]  resync =  1.4% (14078544/976551040)
> finish=501.4min speed=31990K/sec
>    


Resync speed is indeed quite low if you confirm there is no other disk 
activity.
Instead if rsync is also running, you need to stop that one to have a 
proper resync speed measurement (to compute the value to be entered into 
sync_speed_max as per my previous email).
Do you have disk write caches activated? See that with tw_cli (3ware's CLI)
How much is /sys/block/md{n}/md/stripe_cache_size? Pump it up to 32768.

> unused devices:<none>
>
> The drives are connected to a single 3ware Inc 9650SE SATA-II RAID PCIe card
> on this particular system. They're SATA 1GB drives.
>
> Jeremy
>    



  reply	other threads:[~2010-04-12 12:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-12 10:40 stuck tasks Jeremy Sanders
2010-04-12 11:06 ` MRK
2010-04-12 11:14   ` Jeremy Sanders
2010-04-12 12:49     ` MRK [this message]
2010-04-12 13:02       ` Jeremy Sanders
2010-04-12 13:38         ` MRK

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=4BC316EC.9040808@shiftmail.org \
    --to=mrk@shiftmail.org \
    --cc=jeremy@jeremysanders.net \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.