linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* resync to last 27h - usually 3. what's this?
@ 2007-06-18 14:59 Dexter Filmore
  2007-06-18 15:22 ` David Greaves
  0 siblings, 1 reply; 4+ messages in thread
From: Dexter Filmore @ 2007-06-18 14:59 UTC (permalink / raw)
  To: linux-raid

Bootet today, got this in dmesg:

[   44.884915] md: bind<sdd1>
[   44.885150] md: bind<sda1>
[   44.885352] md: bind<sdb1>
[   44.885552] md: bind<sdc1>
[   44.885601] md: kicking non-fresh sdd1 from array!
[   44.885637] md: unbind<sdd1>
[   44.885671] md: export_rdev(sdd1)
[   44.900824] raid5: device sdc1 operational as raid disk 1
[   44.900860] raid5: device sdb1 operational as raid disk 3
[   44.900895] raid5: device sda1 operational as raid disk 2
[   44.901207] raid5: allocated 4203kB for md0
[   44.901241] raid5: raid level 5 set md0 active with 3 out of 4 devices, 
algorithm 2
[   44.901284] RAID5 conf printout:
[   44.901317]  --- rd:4 wd:3
[   44.901349]  disk 1, o:1, dev:sdc1
[   44.901381]  disk 2, o:1, dev:sda1
[   44.901414]  disk 3, o:1, dev:sdb1

Checked the disk, seemed fine (not the first time linux kicked a disk for no 
apparent reason), readded it with mdadm which triggered a resync.
Now having a look at it I get:

$ cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sdd[4] sdc1[1] sdb1[3] sda1[2]
      732563712 blocks level 5, 32k chunk, algorithm 2 [4/3] [_UUU]
      [=>...................]  recovery =  8.1% (19867520/244187904) 
finish=1661.6min speed=2248K/sec

1661 minutes is *way* too long. it's a 4x250GiB sATA array and usually takes 3 
hours to resync or check, for that matter.

So, what's this? 


-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d--(+)@ s-:+ a- C++++ UL++ P+>++ L+++>++++ E-- W++ N o? K-
w--(---) !O M+ V- PS+ PE Y++ PGP t++(---)@ 5 X+(++) R+(++) tv--(+)@ 
b++(+++) DI+++ D- G++ e* h>++ r* y?
------END GEEK CODE BLOCK------

http://www.stop1984.com
http://www.againsttcpa.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: resync to last 27h - usually 3. what's this?
  2007-06-18 14:59 resync to last 27h - usually 3. what's this? Dexter Filmore
@ 2007-06-18 15:22 ` David Greaves
  2007-06-18 16:26   ` Dexter Filmore
  0 siblings, 1 reply; 4+ messages in thread
From: David Greaves @ 2007-06-18 15:22 UTC (permalink / raw)
  To: Dexter Filmore; +Cc: linux-raid

Dexter Filmore wrote:
> 1661 minutes is *way* too long. it's a 4x250GiB sATA array and usually takes 3 
> hours to resync or check, for that matter.
> 
> So, what's this? 
kernel, mdadm verisons?

I seem to recall a long fixed ETA calculation bug some time back...

David

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: resync to last 27h - usually 3. what's this?
  2007-06-18 15:22 ` David Greaves
@ 2007-06-18 16:26   ` Dexter Filmore
  2007-06-18 16:57     ` Justin Piszcz
  0 siblings, 1 reply; 4+ messages in thread
From: Dexter Filmore @ 2007-06-18 16:26 UTC (permalink / raw)
  To: David Greaves; +Cc: linux-raid

On Monday 18 June 2007 17:22:06 David Greaves wrote:
> Dexter Filmore wrote:
> > 1661 minutes is *way* too long. it's a 4x250GiB sATA array and usually
> > takes 3 hours to resync or check, for that matter.
> >
> > So, what's this?
>
> kernel, mdadm verisons?
>
> I seem to recall a long fixed ETA calculation bug some time back...
>

2.6.21.1, mdadm 2.5.3.
First time I sync since upgrade from 2.6.17.

Definetly no calc bug, only 4% progress in one hour.


-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d--(+)@ s-:+ a- C++++ UL++ P+>++ L+++>++++ E-- W++ N o? K-
w--(---) !O M+ V- PS+ PE Y++ PGP t++(---)@ 5 X+(++) R+(++) tv--(+)@ 
b++(+++) DI+++ D- G++ e* h>++ r* y?
------END GEEK CODE BLOCK------

http://www.stop1984.com
http://www.againsttcpa.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: resync to last 27h - usually 3. what's this?
  2007-06-18 16:26   ` Dexter Filmore
@ 2007-06-18 16:57     ` Justin Piszcz
  0 siblings, 0 replies; 4+ messages in thread
From: Justin Piszcz @ 2007-06-18 16:57 UTC (permalink / raw)
  To: Dexter Filmore; +Cc: David Greaves, linux-raid



On Mon, 18 Jun 2007, Dexter Filmore wrote:

> On Monday 18 June 2007 17:22:06 David Greaves wrote:
>> Dexter Filmore wrote:
>>> 1661 minutes is *way* too long. it's a 4x250GiB sATA array and usually
>>> takes 3 hours to resync or check, for that matter.
>>>
>>> So, what's this?
>>
>> kernel, mdadm verisons?
>>
>> I seem to recall a long fixed ETA calculation bug some time back...
>>
>
> 2.6.21.1, mdadm 2.5.3.
> First time I sync since upgrade from 2.6.17.
>
> Definetly no calc bug, only 4% progress in one hour.
>
>
> -- 
> -----BEGIN GEEK CODE BLOCK-----
> Version: 3.12
> GCS d--(+)@ s-:+ a- C++++ UL++ P+>++ L+++>++++ E-- W++ N o? K-
> w--(---) !O M+ V- PS+ PE Y++ PGP t++(---)@ 5 X+(++) R+(++) tv--(+)@
> b++(+++) DI+++ D- G++ e* h>++ r* y?
> ------END GEEK CODE BLOCK------
>
> http://www.stop1984.com
> http://www.againsttcpa.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Hi.

What is your stripe size?

What if you set this higher? By default it will use 1MB/s or so if you do 
not FORCE it to use more than the idle I/O on the box.

echo "Setting minimum and maximum resync speed to 30MB/s..."
echo 30000 > /sys/block/md0/md/sync_speed_min
echo 30000 > /sys/block/md0/md/sync_speed_max
echo 30000 > /sys/block/md1/md/sync_speed_min
echo 30000 > /sys/block/md1/md/sync_speed_max
echo 30000 > /sys/block/md2/md/sync_speed_min
echo 30000 > /sys/block/md2/md/sync_speed_max
echo 30000 > /sys/block/md3/md/sync_speed_min
echo 30000 > /sys/block/md3/md/sync_speed_max



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2007-06-18 16:57 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-06-18 14:59 resync to last 27h - usually 3. what's this? Dexter Filmore
2007-06-18 15:22 ` David Greaves
2007-06-18 16:26   ` Dexter Filmore
2007-06-18 16:57     ` Justin Piszcz

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).