resync duration ?

resync duration ?

[Rainer Fuegenstein]

Hi guys,

I'm a but confused about the duration of a raid5 resync:

- occasionally, my server with 4*750 gb sata raid5 crashed (because of
problems with the power supply); after rebooting it took about 10 to 12
hours to resync the raid5 (guess it just re-created some parity
information or however it works internally, but didn't have to copy
any data)

- right now I replaced one 750GB disk with a 1.5TB disk, but now
resyncing (according to /proc/mdstat) it is supposed to take only 160
minutes ?! although it needs top copy data to a blank disk ?

is this normal or should I be worried, especially before I pull out
the next 750GB disk and replace it with the next 1.5TB disk ?

tnx in advance.

Re: resync duration ?

[Bryan Mesich]

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

On Thu, May 14, 2009 at 03:06:47PM +0200, Rainer Fuegenstein wrote:
> Hi guys,
> 
> I'm a but confused about the duration of a raid5 resync:
> 
> - occasionally, my server with 4*750 gb sata raid5 crashed (because of
> problems with the power supply); after rebooting it took about 10 to 12
> hours to resync the raid5 (guess it just re-created some parity
> information or however it works internally, but didn't have to copy
> any data)
> 
> - right now I replaced one 750GB disk with a 1.5TB disk, but now
> resyncing (according to /proc/mdstat) it is supposed to take only 160
> minutes ?! although it needs top copy data to a blank disk ?

Just a guess...but your problem might be an artifact of a bug
that has been recently fixed.  Neil sent out mail on 2009-05-04
with the fix I'm thinking about.  Here is an excerpt from his
mail:

Subject: [md PATCH 4/7] md: tidy up status_resync to handle
large arrays.

Two problems in status_resync.
1. It still used Kilobytes as the basic block unit, while most
   code now uses sectors uniformly.
2. It doesn't allow for the possibility that max_sectors exceeds
   the range of "unsigned long".

So
 - change "max_blocks" to "max_sectors", and store sector numbers
   in there and in 'resync'
 - Make 'rt' a 'sector_t' so it can temporarily hold the number
   of remaining sectors.
 - use sector_div rather than normal division.
 - change the magic '100' used to preserve precision to '32'.
   + making it a power of 2 makes division easier
   + it doesn't need to be as large as it was chosen when we
   averaged speed over the entire run.  Now we average speed over the
   last 30 seconds or so.

> is this normal or should I be worried, especially before I pull out
> the next 750GB disk and replace it with the next 1.5TB disk ?

If your sync only takes 160 minutes...then I'd start to poke
around.  If its finishing time is reasonable considering the
array size, then I'd continue with the migration.
 
> tnx in advance.

Bryan

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

Re: resync duration ?

[Ryan Wagoner]

Sounds like it could be wrapping around as suggested. Since you are
swapping out all the disks have you thought about stopping the array
and using dd to copy the old disk to the new disk. Then there is no
resync period or degraded array.

Ryan

On Thu, May 14, 2009 at 9:58 AM, Bryan Mesich <bryan.mesich@ndsu.edu> wrote:
> On Thu, May 14, 2009 at 03:06:47PM +0200, Rainer Fuegenstein wrote:
>> Hi guys,
>>
>> I'm a but confused about the duration of a raid5 resync:
>>
>> - occasionally, my server with 4*750 gb sata raid5 crashed (because of
>> problems with the power supply); after rebooting it took about 10 to 12
>> hours to resync the raid5 (guess it just re-created some parity
>> information or however it works internally, but didn't have to copy
>> any data)
>>
>> - right now I replaced one 750GB disk with a 1.5TB disk, but now
>> resyncing (according to /proc/mdstat) it is supposed to take only 160
>> minutes ?! although it needs top copy data to a blank disk ?
>
> Just a guess...but your problem might be an artifact of a bug
> that has been recently fixed.  Neil sent out mail on 2009-05-04
> with the fix I'm thinking about.  Here is an excerpt from his
> mail:
>
> Subject: [md PATCH 4/7] md: tidy up status_resync to handle
> large arrays.
>
> Two problems in status_resync.
> 1. It still used Kilobytes as the basic block unit, while most
>   code now uses sectors uniformly.
> 2. It doesn't allow for the possibility that max_sectors exceeds
>   the range of "unsigned long".
>
> So
>  - change "max_blocks" to "max_sectors", and store sector numbers
>   in there and in 'resync'
>  - Make 'rt' a 'sector_t' so it can temporarily hold the number
>   of remaining sectors.
>  - use sector_div rather than normal division.
>  - change the magic '100' used to preserve precision to '32'.
>   + making it a power of 2 makes division easier
>   + it doesn't need to be as large as it was chosen when we
>   averaged speed over the entire run.  Now we average speed over the
>   last 30 seconds or so.
>
>> is this normal or should I be worried, especially before I pull out
>> the next 750GB disk and replace it with the next 1.5TB disk ?
>
> If your sync only takes 160 minutes...then I'd start to poke
> around.  If its finishing time is reasonable considering the
> array size, then I'd continue with the migration.
>
>> tnx in advance.
>
> Bryan
>
--
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

Re[2]: resync duration ?

[Rainer Fuegenstein]

guys,

It's amazing - it really finished resyncing after about 160 minutes.
cpu load went down to 0.1 (from about 2.70) and there was nearly no
disk activity. looks like it was really that fast and not just
displaying a false estimate. (and yes, the xfs file system on top if
it seems to be intact, at least for now).

RW> Sounds like it could be wrapping around as suggested. Since you are
RW> swapping out all the disks have you thought about stopping the array
RW> and using dd to copy the old disk to the new disk. Then there is no
RW> resync period or degraded array.

I'm not feeling comfortable with dd'ing from/to disks of different
sizes/layouts. and I'd like to avoid long downtimes of the server.
Originally I planned to add 2 2port sata controllers and install the
new disks in parallel (as suggested by chris), but that didn't
work out so well.

anyway, over night I'll backup the most important data to the disk I
just pulled out (and will do so with the other disks as I pull them
out). will replace the second disk tomorrow.

I'll let you know of success or failure as the story progresses.


RW> Ryan

RW> On Thu, May 14, 2009 at 9:58 AM, Bryan Mesich <bryan.mesich@ndsu.edu> wrote:
>> On Thu, May 14, 2009 at 03:06:47PM +0200, Rainer Fuegenstein wrote:
>>> Hi guys,
>>>
>>> I'm a but confused about the duration of a raid5 resync:
>>>
>>> - occasionally, my server with 4*750 gb sata raid5 crashed (because of
>>> problems with the power supply); after rebooting it took about 10 to 12
>>> hours to resync the raid5 (guess it just re-created some parity
>>> information or however it works internally, but didn't have to copy
>>> any data)
>>>
>>> - right now I replaced one 750GB disk with a 1.5TB disk, but now
>>> resyncing (according to /proc/mdstat) it is supposed to take only 160
>>> minutes ?! although it needs top copy data to a blank disk ?
>>
>> Just a guess...but your problem might be an artifact of a bug
>> that has been recently fixed.  Neil sent out mail on 2009-05-04
>> with the fix I'm thinking about.  Here is an excerpt from his
>> mail:
>>
>> Subject: [md PATCH 4/7] md: tidy up status_resync to handle
>> large arrays.
>>
>> Two problems in status_resync.
>> 1. It still used Kilobytes as the basic block unit, while most
>>   code now uses sectors uniformly.
>> 2. It doesn't allow for the possibility that max_sectors exceeds
>>   the range of "unsigned long".
>>
>> So
>>  - change "max_blocks" to "max_sectors", and store sector numbers
>>   in there and in 'resync'
>>  - Make 'rt' a 'sector_t' so it can temporarily hold the number
>>   of remaining sectors.
>>  - use sector_div rather than normal division.
>>  - change the magic '100' used to preserve precision to '32'.
>>   + making it a power of 2 makes division easier
>>   + it doesn't need to be as large as it was chosen when we
>>   averaged speed over the entire run.  Now we average speed over the
>>   last 30 seconds or so.
>>
>>> is this normal or should I be worried, especially before I pull out
>>> the next 750GB disk and replace it with the next 1.5TB disk ?
>>
>> If your sync only takes 160 minutes...then I'd start to poke
>> around.  If its finishing time is reasonable considering the
>> array size, then I'd continue with the migration.
>>
>>> tnx in advance.
>>
>> Bryan
>>
RW> --
RW> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
RW> the body of a message to majordomo@vger.kernel.org
RW> More majordomo info at  http://vger.kernel.org/majordomo-info.html


------------------------------------------------------------------------------
Unix gives you just enough rope to hang yourself -- and then a couple of more 
feet, just to be sure.
(Eric Allman)
------------------------------------------------------------------------------

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

Re: resync duration ?

[John Robinson]

On 14/05/2009 14:58, Bryan Mesich wrote:
[...]
> If your sync only takes 160 minutes...then I'd start to poke
> around.  If its finishing time is reasonable considering the
> array size, then I'd continue with the migration.

I think about 160 minutes is reasonable for 750GB, on an otherwise 
unloaded box; it's only 70MB/sec off 3 drives and on to 1 newer, faster 
drive.

Cheers,

John.

Re: resync duration ?

[Bryan Mesich]

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

On Thu, May 14, 2009 at 06:06:51PM +0100, John Robinson wrote:
> I think about 160 minutes is reasonable for 750GB, on an otherwise  
> unloaded box; it's only 70MB/sec off 3 drives and on to 1 newer, faster  
> drive.

I have a similar setup with 4 750G SATA drives.  The box is
failry beefy, with 8 processor cores and a PCI-E SATA controler
(3Ware 9650SE).  For an initial sync, it will take about 315
minutes to complete.

I'm not sure if this is a fair comparison, since Rainer was do a
resync.

md8 : active raid5 sdx1[4] sdw1[2] sdv1[1] sdu1[0]
      2197209600 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_]
      [>....................]  recovery =  1.6% (12015536/732403200) finish=312.3min speed=38437K/sec

I'm probably splitting hairs at this point.

Bryan

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

Re: resync duration ?

[Richard Scobie]

Bryan Mesich wrote:
> On Thu, May 14, 2009 at 06:06:51PM +0100, John Robinson wrote:
> 
>>I think about 160 minutes is reasonable for 750GB, on an otherwise  
>>unloaded box; it's only 70MB/sec off 3 drives and on to 1 newer, faster  
>>drive.
> 
> 
> I have a similar setup with 4 750G SATA drives.  The box is
> failry beefy, with 8 processor cores and a PCI-E SATA controler
> (3Ware 9650SE).  For an initial sync, it will take about 315
> minutes to complete.
> 
> I'm not sure if this is a fair comparison, since Rainer was do a
> resync.
> 
> md8 : active raid5 sdx1[4] sdw1[2] sdv1[1] sdu1[0]
>       2197209600 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_]
>       [>....................]  recovery =  1.6% (12015536/732403200) finish=312.3min speed=38437K/sec
> 
> I'm probably splitting hairs at this point.
> 
> Bryan

Just to add another data point, I replaced a dead 750GB drive in 4 x 750 
md RAID5 last week and it took 145 minutes.

Resync on another 16 x 750GB md RAID6 takes around 180min.

Regards,

Richard

Re: resync duration ?

[Neil Brown]

On Thursday May 14, rfu@kaneda.iguw.tuwien.ac.at wrote:
> Hi guys,
> 
> I'm a but confused about the duration of a raid5 resync:
> 
> - occasionally, my server with 4*750 gb sata raid5 crashed (because of
> problems with the power supply); after rebooting it took about 10 to 12
> hours to resync the raid5 (guess it just re-created some parity
> information or however it works internally, but didn't have to copy
> any data)

A resync reads all the data and checks the parity.  If it find bad
parity (which is likely to be very rare) then it corrects it.
So resync should run at the full speed of the hardware, just reading.

> 
> - right now I replaced one 750GB disk with a 1.5TB disk, but now
> resyncing (according to /proc/mdstat) it is supposed to take only 160
> minutes ?! although it needs top copy data to a blank disk ?
> 
> is this normal or should I be worried, especially before I pull out
> the next 750GB disk and replace it with the next 1.5TB disk ?

recovery reads N-1 drives and writes the N'th drive.  So it shuffles
exactly the same amount of data as sync, and performs just as many IO
operations, though some of them are writes rather than reads.  I
believe that (on rotating drives) writes go at much the same speed as
reads.
So you would expect this to take exactly as long as the resync.

As others have said, 3 hours it a reasonable ball-part for 750Gig.
10-12 hours is definitely longer than I would expect.

Of course, if use are using the array then resync (or recovery) will
back off and let the regular IO have priority.  So if you were
actively using the array during the 10-12 hours resync, then it makes
perfect sense.

NeilBrown

RE: resync duration ?

[Leslie Rhorer]

> > I'm a but confused about the duration of a raid5 resync:
> >
> > - occasionally, my server with 4*750 gb sata raid5 crashed (because of
> > problems with the power supply); after rebooting it took about 10 to 12
> > hours to resync the raid5 (guess it just re-created some parity
> > information or however it works internally, but didn't have to copy
> > any data)
> 
> A resync reads all the data and checks the parity.  If it find bad
> parity (which is likely to be very rare) then it corrects it.
> So resync should run at the full speed of the hardware, just reading.

It will?  Maybe I am just mis-remembering, but I thought I saw the same note
in the log when the resync occurred (ckarray) as when a recovery was in
progress:

May 14 22:40:42 Backup kernel: [ 8083.747787] md: recovery of RAID array md0
May 14 22:40:42 Backup kernel: [ 8083.747789] md: minimum _guaranteed_
speed: 1000 KB/sec/disk.
May 14 22:40:42 Backup kernel: [ 8083.747791] md: using maximum available
idle IO bandwidth (but not more than 200000 KB/sec) for recovery.
May 14 22:40:42 Backup kernel: [ 8083.747797] md: using 128k window, over a
total of 1465138432 blocks.

Am I mis-remembering, or am I missing something here?

Oh, while I am thinking of it, ckarray runs every month on the first of the
month, but how can one trigger it manually?

RE: resync duration ?

[NeilBrown]

On Fri, May 15, 2009 2:04 pm, Leslie Rhorer wrote:
>> > I'm a but confused about the duration of a raid5 resync:
>> >
>> > - occasionally, my server with 4*750 gb sata raid5 crashed (because of
>> > problems with the power supply); after rebooting it took about 10 to
>> 12
>> > hours to resync the raid5 (guess it just re-created some parity
>> > information or however it works internally, but didn't have to copy
>> > any data)
>>
>> A resync reads all the data and checks the parity.  If it find bad
>> parity (which is likely to be very rare) then it corrects it.
>> So resync should run at the full speed of the hardware, just reading.
>
> It will?  Maybe I am just mis-remembering, but I thought I saw the same
> note
> in the log when the resync occurred (ckarray) as when a recovery was in
> progress:
>
> May 14 22:40:42 Backup kernel: [ 8083.747787] md: recovery of RAID array
> md0
> May 14 22:40:42 Backup kernel: [ 8083.747789] md: minimum _guaranteed_
> speed: 1000 KB/sec/disk.
> May 14 22:40:42 Backup kernel: [ 8083.747791] md: using maximum available
> idle IO bandwidth (but not more than 200000 KB/sec) for recovery.
> May 14 22:40:42 Backup kernel: [ 8083.747797] md: using 128k window, over
> a
> total of 1465138432 blocks.
>
> Am I mis-remembering, or am I missing something here?

It isn't clear to me exactly what you are asking...

It says it won't use more than 200MB/sec, which is true. But that is
per-device, and few devices can deliver that yet.

It says "using maximum available", so it if you want the bandwidth
for something else, it will back off.

It prints the same message for resync as for recovery.



>
> Oh, while I am thinking of it, ckarray runs every month on the first of
> the
> month, but how can one trigger it manually?

  echo check > /sys/block/mdX/md/sync_action.

or "echo repair" to get it to fix anything it finds.

NeilBrown

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

RE: resync duration ?

[Leslie Rhorer]

> >> A resync reads all the data and checks the parity.  If it find bad
> >> parity (which is likely to be very rare) then it corrects it.
> >> So resync should run at the full speed of the hardware, just reading.
> >
> > It will?  Maybe I am just mis-remembering, but I thought I saw the same
> > note
> > in the log when the resync occurred (ckarray) as when a recovery was in
> > progress:
> >
> > May 14 22:40:42 Backup kernel: [ 8083.747787] md: recovery of RAID array
> > md0
> > May 14 22:40:42 Backup kernel: [ 8083.747789] md: minimum _guaranteed_
> > speed: 1000 KB/sec/disk.
> > May 14 22:40:42 Backup kernel: [ 8083.747791] md: using maximum
> available
> > idle IO bandwidth (but not more than 200000 KB/sec) for recovery.
> > May 14 22:40:42 Backup kernel: [ 8083.747797] md: using 128k window,
> over
> > a
> > total of 1465138432 blocks.
> >
> > Am I mis-remembering, or am I missing something here?
> 
> It isn't clear to me exactly what you are asking...
> 
> It says it won't use more than 200MB/sec, which is true. But that is
> per-device, and few devices can deliver that yet.

Oh.  I thought it meant for the entire array.  Yeah, 200MBps is pretty far
out there, at least for a sustained rate.  SATA II can burst to that, but
few drives can manage much more than 50 MBps, sustained.

> It says "using maximum available", so it if you want the bandwidth
> for something else, it will back off.
> 
> It prints the same message for resync as for recovery.

Ah, so I'm not going crazy, I just have a comprehension problem.

Hmmm.  I'm not sure which is worse. :-)

> > Oh, while I am thinking of it, ckarray runs every month on the first of
> > the
> > month, but how can one trigger it manually?
> 
>   echo check > /sys/block/mdX/md/sync_action.
> 
> or "echo repair" to get it to fix anything it finds.

Thanks.  Those are pretty easy, but it would be nice if they were in the MAN
page.  Better yet, have you considered adding both as command line options
for mdadm?

Re: resync duration ?

[Richard Scobie]

Leslie Rhorer wrote:

> Thanks.  Those are pretty easy, but it would be nice if they were in the MAN
> page.  Better yet, have you considered adding both as command line options
> for mdadm?

This (and other md info0 is contained in the kernel source 
Documentation/md.txt.

Regards,

Richard

RE: resync duration ?

[Neil Brown]

On Friday May 15, lrhorer@satx.rr.com wrote:
> > 
> >   echo check > /sys/block/mdX/md/sync_action.
> > 
> > or "echo repair" to get it to fix anything it finds.
> 
> Thanks.  Those are pretty easy, but it would be nice if they were in the MAN
> page.  Better yet, have you considered adding both as command line options
> for mdadm?

Considered, yes.  But they are very low on my priority list.
I accept patches.
Maybe and option like
   mdadm --syncaction=check /dev/md0

??

NeilBrown

Re: resync duration ?

[Richard Scobie]

Neil Brown wrote:

> Considered, yes.  But they are very low on my priority list.
> I accept patches.
> Maybe and option like
>    mdadm --syncaction=check /dev/md0

Perhaps it could also be incorporated in a manner similar to the way 
smartd allows for scheduled tests - a parameter added to each array in 
the mdadm.conf would allow scheduled checks when mdadm is run as a  daemon.

Regards,

Richard

Re: resync duration ?

[NeilBrown]

On Sat, May 16, 2009 12:47 pm, Richard Scobie wrote:
> Neil Brown wrote:
>
>> Considered, yes.  But they are very low on my priority list.
>> I accept patches.
>> Maybe and option like
>>    mdadm --syncaction=check /dev/md0
>
> Perhaps it could also be incorporated in a manner similar to the way
> smartd allows for scheduled tests - a parameter added to each array in
> the mdadm.conf would allow scheduled checks when mdadm is run as a
> daemon.

Thanks for the suggestion...

However I have the strange and old-fashion notion that the strength
of Unix (which is one of the foundations of Linux) is the "tools
approach".  You have a tool for each job, and it does the job properly.

In the case of scheduled checks. cron is the tool of choice.

So if you want a monthly, or yearly, or daily check, get cron
to schedule it.

Just like if you want to be regularly reminded about degraded arrays,
get cron to run "mdadm -monitor --oneshot --scan" every morning.

I am definitely not interested in adding any scheduling capabilities
to mdadm.
(is smartd does scheduled checks... more fool them :-)

NeilBrown

Re: resync duration ?

[Bill Davidsen]

Neil Brown wrote:
> On Friday May 15, lrhorer@satx.rr.com wrote:
>   
>>>   echo check > /sys/block/mdX/md/sync_action.
>>>
>>> or "echo repair" to get it to fix anything it finds.
>>>       
>> Thanks.  Those are pretty easy, but it would be nice if they were in the MAN
>> page.  Better yet, have you considered adding both as command line options
>> for mdadm?
>>     
>
> Considered, yes.  But they are very low on my priority list.
> I accept patches.
> Maybe and option like
>    mdadm --syncaction=check /dev/md0
>
> ??
>   

That is a great idea, it puts the md administration in the mdadm program 
(where it belongs) instead of counting on a script to do the right 
thing. Well, if you do this at all, the other actions are probably 
appropriate as well.

-- 
bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc

"You are disgraced professional losers. And by the way, give us our money back."
    - Representative Earl Pomeroy,  Democrat of North Dakota
on the A.I.G. executives who were paid bonuses  after a federal bailout.

Re: resync duration ?

[John Robinson]

On 18/05/2009 16:00, Bill Davidsen wrote:
> Neil Brown wrote:
[...]
>> Maybe and option like
>>    mdadm --syncaction=check /dev/md0
>>
>> ??
> 
> That is a great idea, it puts the md administration in the mdadm program 
> (where it belongs) instead of counting on a script to do the right 
> thing. Well, if you do this at all, the other actions are probably 
> appropriate as well.

It would be nice if such a thing blocked until completion and reported 
the results of the sync action, instead of or as well as them going to 
the system log, so they can be emailed by cron or otherwise examined by 
the caller.

I know, I know, you accept patches :-) but my coding skills are way too 
rusty to attempt this.

Cheers,

John.

Re: resync duration ?

[Rainer Fuegenstein]

> As others have said, 3 hours it a reasonable ball-part for 750Gig.
> 10-12 hours is definitely longer than I would expect.
>
> Of course, if use are using the array then resync (or recovery) will
> back off and let the regular IO have priority.  So if you were
> actively using the array during the 10-12 hours resync, then it makes
> perfect sense.

That's what puzzles me: the server is used just for storage and usually
there are nearly no accesses during the 10-12h resync period. whereas
(according to your statement above) when accessing the raid with the one
new 1.5TB disk during the 3h resync period, the estimate climbs to about
1600 minutes, but drops back to 3 hours when idle again.

could this be a result of the hardware configuration ?

old 750GB disk:
  Vendor: ATA       Model: SAMSUNG HD753LJ   Rev: 1AA0
  Type:   Direct-Access                      ANSI SCSI revision: 05

new 1.5TB disk: (western digital caviar green)
  Vendor: ATA       Model: WDC WD15EADS-00R  Rev: 01.0
  Type:   Direct-Access                      ANSI SCSI revision: 05

$ cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 127
model name      : AMD Sempron(tm) Processor LE-1200
stepping        : 1
cpu MHz         : 1800.000
cache size      : 512 KB
[...]

mainboard is an ASUS M2N with 4 onbord SATA ports.

anyway, when all the 1.5TB disks are active in the raid5, I'll simulate a
power failure and see how long the re-sync will take then.

Re: resync duration ?

[Bill Davidsen]

Rainer Fuegenstein wrote:
> Hi guys,
>
> I'm a but confused about the duration of a raid5 resync:
>
> - occasionally, my server with 4*750 gb sata raid5 crashed (because of
> problems with the power supply); after rebooting it took about 10 to 12
> hours to resync the raid5 (guess it just re-created some parity
> information or however it works internally, but didn't have to copy
> any data)
>
>   
I have a test machine which crashes regularly (used for kernel and 
hardware tests), and that sounds long. Are you running without a bitmap, 
by any chance?

> - right now I replaced one 750GB disk with a 1.5TB disk, but now
> resyncing (according to /proc/mdstat) it is supposed to take only 160
> minutes ?! although it needs top copy data to a blank disk ?
>
> is this normal or should I be worried, especially before I pull out
> the next 750GB disk and replace it with the next 1.5TB disk ?
>
> tnx in advance.
>
> --
> 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
>
>   


-- 
bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc

"You are disgraced professional losers. And by the way, give us our money back."
    - Representative Earl Pomeroy,  Democrat of North Dakota
on the A.I.G. executives who were paid bonuses  after a federal bailout.