Very slow copying data from RAID 1 array.

[Ian R]

Hi

I have a 500GB RAID1 array using brand new Western Digital drives and the
Sil 3114 chipset on my ASUS A8N-SLI Premium system board.

I use the RAID to store partition backup image files which are split into
multiple 2GB segments. The backup segments total approx 70Gb.

Each week I copy the image files to a removable hard drive which usually
takes approx 25-30mins.

However today after selecting all the segments (77GB Total) and beginning
the copy,
Windows is estimating over 200 minutes for the copying!

I had similar trouble a few months ago so ran a disc check on the RAID array
which took over 30hrs to complete! It seemed to fix whatever errors it
found as since then it ran normally taking approx 25-30mins to copy the
files.

However today the same lengthy copying problem has recurred.

Any idea what might cause this?

Right now I'm thinking I'll need to reformat the drives but I'll have to buy
another 500GB drive to painstakingly copy all the data off the RAID array
first! Bummer!

Thanks for any info.

Ian

 

[Arno Wagner]

Hi

I have a 500GB RAID1 array using brand new Western Digital drives and the
Sil 3114 chipset on my ASUS A8N-SLI Premium system board.

I use the RAID to store partition backup image files which are split into
multiple 2GB segments. The backup segments total approx 70Gb.

Each week I copy the image files to a removable hard drive which usually
takes approx 25-30mins.

However today after selecting all the segments (77GB Total) and beginning
the copy,
Windows is estimating over 200 minutes for the copying!

I had similar trouble a few months ago so ran a disc check on the RAID array
which took over 30hrs to complete! It seemed to fix whatever errors it
found as since then it ran normally taking approx 25-30mins to copy the
files.

However today the same lengthy copying problem has recurred.

Any idea what might cause this?

Right now I'm thinking I'll need to reformat the drives but I'll have to buy
another 500GB drive to painstakingly copy all the data off the RAID array
first! Bummer!

Thanks for any info.

Ian

30 min for 77GB is about 42MB/s. That is pretty good. 200 min
is about 6MB/s. Quite slow. May be PIO instead of DMA
on a disk (bad cabeling), may be excessive fragmentation.
May also be bad sectors or other disk issues.

Do not replace the disks before you have have diagnised the
problem. At the moment it need not be the disks themselves.

Arno

 

[231]

30 min for 77GB is about 42MB/s. That is pretty good. 200 min
is about 6MB/s. Quite slow. May be PIO instead of DMA on a disk
Yes.

(bad cabeling),

Or something else turned the DMA off.

may be excessive fragmentation.

Nope, you wont get that dramatic a result from that.

May also be bad sectors or other disk issues.

Yep. And the best way to check for that is the SMART report,
after breaking the RAID array if necessary to do that.

 

[Ian R]

30 min for 77GB is about 42MB/s. That is pretty good. 200 min
is about 6MB/s. Quite slow. May be PIO instead of DMA
on a disk (bad cabeling), may be excessive fragmentation.
May also be bad sectors or other disk issues.

Do not replace the disks before you have have diagnised the
problem. At the moment it need not be the disks themselves.

Arno

Hi Arno

Thanks for replying.

Ive checked all the settings for the disk drives, SATA controller and RAID
controller in device manager as well as disc settings in disk management but
I cant see anywhere to check or alter the transfer mode to the RAID array.

I've downloaded and installed the lastest WD Data Lifeguard Tools but it
didnt report any problems and it seems pretty sparse in that it doesnt seem
to offer any diagnostic utilities.

Are there third party utilities I can run which can check the drives while
they are still part of the RAID?

I'm *slowly* moving stuff off the RAID - buring to DVD-R but its painfully
slow. Ive got an 18x DVD burner and with Verbatim discs I can usually burn
at 18x. But tonight Nero says.. "can only write at 4x because the speed of
the source data is too slow".

As if I didnt know!

Cheers

Ian

 

[Arno Wagner]

Or something else turned the DMA off.

Nope, you wont get that dramatic a result from that.

Oh, yes. You can get even worse. I have seen it. Remember that
this is an average over 77GB.

Yep. And the best way to check for that is the SMART report,
after breaking the RAID array if necessary to do that.

Actually the way to do this is to attach the disks to a different
controller and never acess them in R/W mode. E.g. Knoppix
can help here.

Arno

 

[Arno Wagner]

Hi Arno

Thanks for replying.

Ive checked all the settings for the disk drives, SATA controller and RAID
controller in device manager as well as disc settings in disk management but
I cant see anywhere to check or alter the transfer mode to the RAID array.

I've downloaded and installed the lastest WD Data Lifeguard Tools but it
didnt report any problems and it seems pretty sparse in that it doesnt seem
to offer any diagnostic utilities.

Are there third party utilities I can run which can check the drives while
they are still part of the RAID?

You can remove both disks, attach each one to a different
controller and use a Knoppix CD only Linux to get their SMART
status, and in addition run a long SMART selftest. The tool for
this is smartctl. Knoppix mounts the disks readonly, so they will
form a valid RAID again, when connected back to the RAID controller.

I'm *slowly* moving stuff off the RAID - buring to DVD-R but its
painfully slow. Ive got an 18x DVD burner and with Verbatim discs I
can usually burn at 18x. But tonight Nero says.. "can only write at
4x because the speed of the source data is too slow".

As if I didnt know!

Hm. Maybe get a cheap external USB HDD and move everytginh there?
You could do this overnight and unattended.

Arno

 

[231]

Oh, yes.
Nope.

You can get even worse.
Nope.

I have seen it.

No you havent.

Remember that this is an average over 77GB.

You cant get a 7/1 reduction in thruput due to excessive fragmentation.

The size is irrelevant to that.

Actually the way to do this is to attach the disks to a
different controller and never acess them in R/W mode.

What I said in different words.

 

[Arno Wagner]

No you havent.

You cant get a 7/1 reduction in thruput due to excessive fragmentation.

The size is irrelevant to that.

You have no clue what you are talking about, obviously. The worst
case, and it can be reached in practice, is one seek per cluster. If
we assume 16kB clusters and a 7200rpm disk with 10ms seek time and 4ms
average latency, that comes down to just over 1MB/s. That is without
any accesses for the management information and time to actually read
anything.

Arno

 

[Eric Gisin]

You have no clue what you are talking about, obviously. The worst
case, and it can be reached in practice, is one seek per cluster. If
we assume 16kB clusters and a 7200rpm disk with 10ms seek time and 4ms
average latency, that comes down to just over 1MB/s. That is without
any accesses for the management information and time to actually read
anything.

You have no real world experience. Free clusters come in runs, not randomly scattered.

 

[231]

You have no clue what you are talking about, obviously.

We'll see...

The worst case, and it can be reached in practice, is one seek per cluster.

That never ever happens in practice.

If we assume 16kB clusters and a 7200rpm disk with 10ms seek
time and 4ms average latency, that comes down to just over 1MB/s.
Nope.

That is without any accesses for the management
information and time to actually read anything.

Wrong, as always.

 

[Arno Wagner]

We'll see...

That never ever happens in practice.

Wrong, as always.

Obviously you cannot do basic arithmetric. No use
arguing with this level of incompetence.

Arno

 

[mscotgrove]

Arno- Hide quoted text -

- Show quoted text -

I think the question of theoretical slowing down due to fragmentation
is irrelevant. A heavily fragmented drive can be slower, but not by
much.

A drive with failing physical sectors, requiring many retries will be
slow, I think this is were you need to investiagte

Personally I would advise against doing a backup onto DVDs as they are
not always 100% reliable. A 500GB drive, as suggested above is simple
and you are less likely to miss out any files. If you hit a very slow
part reading your master disk, the DVD copy may fail, but your hard
drive copy will be fine.


Michael
www.cnwrecovery.com

 

[Arno Wagner]

I think the question of theoretical slowing down due to fragmentation
is irrelevant. A heavily fragmented drive can be slower, but not by
much.

I am just saying that in cetain pathological situations it can
reach the slow speed stated. It is quite unlikely to happen
in practice, but the observes problem is as well.

A drive with failing physical sectors, requiring many retries will be
slow, I think this is were you need to investiagte

Indeed. A very likely explanation.

Arno

 

[231]

I am just saying that in cetain pathological
situations it can reach the slow speed stated.

No it cant, because those fantasys never happen in the real world.

It is quite unlikely to happen in practice,

Impossible, actually.

but the observes problem is as well.

Wrong, as always.

 

[231]

Obviously you cannot do basic arithmetric.

Obviously you have never ever been able to bullshit your way out of a wet paper bag.

No use arguing with this level of incompetence.

Your pathetic excuse for bullshit in spades.

 

[Folkert Rienstra]

Arno Wagner wrote in news:[email protected]

30 min for 77GB is about 42MB/s. That is pretty good.

200 min is about 6MB/s. Quite slow.

Depends on how crowded the source and/or destination directories are.

May be PIO instead of DMA on a disk (bad cabeling),

PIO on SATA, babblebot? Have you fallen off your beliefs now.

may be excessive fragmentation.
May also be bad sectors

May be Gods hand too, right babblebot?

or other disk issues.

Yep, that should about sum it up.

 

[Folkert Rienstra]

Arno Wagner wrote in news:[email protected]
The key word here is "estimating".

Oh, yes. You can get even worse. I have seen it.

That's what a cooked brain does for you, babblebot.

Remember that this is an average over 77GB.

Exactly. Which is exactly why that value is so *dramatic*, babblebot.
It means that the low(est) values in the range that make up for
that average must be even *dramatically* low(er than 6MB/s).
With 1MB/s being the bottom for that, that means a very high
(ie *dramatic*) degree of fragmentation.

Actually the way to do this is to attach the disks to a different controller

Nope, if breaking the array is yielding the same result.

and never acess them in R/W mode.

Which isn't necessarily a problem.

 

[Folkert Rienstra]

231 wrote in news:[email protected]

We'll see...


That never ever happens in practice.

16 kB / 80 MB/s = .2 ms per cluster transfer time (!)
1 cluster per 14.4 ms = 70 clusters per second = 1.11 MB/s average

Or from a dutycycle perspective:
..2 / (10 + 4.2 + .2) * 80 MB/s = 1.11 MB/s average

(!) 80MB/s STR for convenience, but not unrealistic.

Nope.

Nope, Roddles?