DELL PERC H310 slow copying across the array

[thebaldconvict]

Hi all,

 

I am wondering would anybody with the Dell PERC H310 flashed to IT mode be able to comment re write speeds to their array?

 

I currently have a cache drive, an unassigned disk and two parity disks on my motherboard with all the data disks of my array on the H310 and am having some speed issues. sorry for the long ramble that is coming!!

 

So if I use the script I found here on these forums called write_speed_test.sh and run it on each disk individually all of the disks start at about 200MB/s and slowly drop to around 130MB/s, except the SSD cache drive which appears to start at around 500MB/s and drop to around 200MB/s, a little slower than expected but I can live with that.

 

So, if for example I test the speed of disk6, I get 130MB/s, the unassigned disk I see about the same (maybe a little slower, it is an old 1TB WD Blue)

If I test the SSD at the same time as testing the unassigned disk (both motherboard disks) I get pretty much the same results.

If I test say array disk6 and a motherboard disk I get normal speeds from the motherboard connected drive but only around 60MB/s from the H310 disk.

If I then test say disk5 while writing to disk6 (Both on the H310 and directly in reconstruct write mode) I get around 15-20MB/s on each and this is how it behaves most of the time.

 

Is this a limitation of the H310 or my motherboard/cpu or something else? Its been this way for a while now but it only annoyed me yesterday when it took 4.5 hours to move a 256GB file from the unassigned disk to the array.

 

 

Cheers all

 

Tim

[JorgeB]

4 minutes ago, thebaldconvict said:

If I then test say disk5 while writing to disk6 (Both on the H310 and directly in reconstruct write mode) I get around 15-20MB/s on each and this is how it behaves most of the time.

That's expected since parity will be updated for both disks at the same time, so it will be much slower, for best performance with unRAID you can only write to one disk at a time.

[thebaldconvict]

If I'm doing a reconstruct write I thought that removed the parity disks from the equation while doing that write? 

 

is 15-20MB/s really all I can get? What happens if I copy two files to the array and they go to different disks? Is that why sometimes I see it drop to 5/6MB/s?

[pwm]

12 hours ago, thebaldconvict said:

If I'm doing a reconstruct write I thought that removed the parity disks from the equation while doing that write? 

 

is 15-20MB/s really all I can get? What happens if I copy two files to the array and they go to different disks? Is that why sometimes I see it drop to 5/6MB/s?

Reconstruct write just removes the read/modify/write step which means it can give a very high bandwidth when you write to one data disk.

But when you write to two data disks, then each of the writes represents a specific LBA that needs to be processed on all disks (write for the specific data disk and the parity disk(s) and read for the other data disks). Since the two writes to different disks will affect different LBA, that means the parity disk(s) will have to perform a large number of seek to jump between the two different locations that parity needs to be updated. It's the same result you get as if you try to read and write two different files from a single data disk - the total bandwidth will be a small fraction of the bandwidth you can get for a single file because of all the seek latencies - the time spent seeking is time then disk will not do any read or write so the bandwidth will drop very sharply.

[JorgeB]

12 hours ago, thebaldconvict said:

is 15-20MB/s really all I can get? What happens if I copy two files to the array and they go to different disks? Is that why sometimes I see it drop to 5/6MB/s?

Most likely, you want to optimize your share settings, e.g., avoid using most free, so that files don't go to multiple disks simultaneously.

[thebaldconvict]

Thanks both for your help and thank you for that explanation PWM and just thinking about that description, I might want to swap out my parity disks which from what I've been reading are shingled disks... Although I've also read that Unraid is fine with SMR disks so who knows.

 

I was swapping my parity disks to 8TB disks but have only done one so far so I have a ST4000LM024 and a ST8000AS0002 as the parity disks, maybe wise to swap them with 2x PMR drives as I've read that even the 4TB is an SMR?

[John_M]

6 hours ago, thebaldconvict said:

I was swapping my parity disks to 8TB disks but have only done one so far so I have a ST4000LM024 and a ST8000AS0002 as the parity disks, maybe wise to swap them with 2x PMR drives as I've read that even the 4TB is an SMR?

 

I would have no problem using Seagate Archive drives as data disks because the huge majority of my writes consist of sequentially copying files from my workstation to my server. I would be dubious about using them for parity disks because of the read-modify-write process, which is not best suited to shingled media. Some people report success in using them for parity but perhaps they write only small batches of files (i.e. not enough to fill the persistent cache) in one session. The reason I haven't used Archive drives is because IronWolfs cost the same and WD Reds only a little more.

 

I don't know if all BarraCuda Compute drives are shingled but the higher capacity ones certainly are. They are also inferior to Archive drives because the have a low workload rate of only 55 TB/year. They are best left inside their external USB cases and connected occasionally for backup purposes. It's a shame that SMR has become associated with low performance, low reliability drives. In the 3.5-inch form factor they don't even have the advantage of large capacity any more. I'm rather disappointed not to have seen a 16 or 20 TB Archive drive by now, with the persistent cache implemented in NAND flash, as it is on Seagate's 2.5-inch SMR products.

 

Please note that shingled drives also use perpendicular recording so PMR does not mean "not SMR". I'm not saying this to be pedantic but because Seagate seems rather coy about mentioning SMR in its documentation and people have confused themselves by reading PMR and assuming that shingled media were not being used.

[JorgeB]

I have a server with Archive SMR drives only, including parity, and never had performance issues, but it's most write only and I only do only large file sequential transfers, they might perform worse with random writes and/or transferring a lot of small files.

[John_M]

I have a couple of Archive drives in an external eSATA case. Dragging and dropping a folder full of files onto it works fine. Dragging a second folder onto it while the first copy is in progress fills up the persistent cache and kills performance. The NAND flash implementation of the persistent cache used on the 2.5-inch SMR drives works much better because it reduces the number of head seeks enormously. I use a pair of those (4 TB each in USB cases) for Macintosh Time Machine backups - lots of random writes - and they work very well indeed.