Unraid Pro copies ~16MB/s internally on same motherboard limetech uses?

[atari]

 

Hardware:

 

I'm using the hardware that LimeTechnology currently sells in the systems they build - minus the extra pci-e sata2 cards (only using cards onboard C2SEE).

 

Components:

Supermicro C2SEE motherboard

E5200 CPU

Corsair 2GB DDR3 memory

4x Seagate 1.5 TB drives

1x Samsung HD103UJ 1TB drive

 

 

 

 

The Samsung drive hdparam results:

# hdparm -tT /dev/sde

 

/dev/sde:

Timing cached reads:  2566 MB in  2.00 seconds = 1283.94 MB/sec

Timing buffered disk reads:  352 MB in  3.02 seconds = 116.74 MB/sec

 

The Seagates look like this:

 

/dev/sda:

Timing cached reads:  2528 MB in  2.00 seconds = 1264.90 MB/sec

Timing buffered disk reads:  382 MB in  3.01 seconds = 126.91 MB/sec

 

 

 

But when I use mc to copy files between them, I get ~16MB/s according to mc.

 

This seems pretty slow?

 

No write-cache drive set up yet.... but is it really this slow?

[prostuff1]

This is about normal as you have to take into account the parity that is being calculated for each one of those read and writes.  There was a good explanation of it somewhere but i am to lazy to find the link… sorry.

[Biggy2872]

This is about normal as you have to take into account the parity that is being calculated for each one of those read and writes.  There was a good explanation of it somewhere but i am to lazy to find the link… sorry.

 

I believe you are talking about bjp999's post here: http://lime-technology.com/forum/index.php?topic=3454.msg29810#msg29810

 

Cheers,

Matt

[atari]

ack. Well... that kind of sucks.  I suppose the price to pay for data integrity.

 

I'll hook up a cache drive asap

[RobJ]

That 16MB/s sounds amazing, possibly the best I've heard.  You have to remember that it is not just that writing to a parity protected drive involves 4 times the drive I/O, but that also the 2 initial reads are followed by 2 writes to the same sectors.  That means it has to wait for a complete rotation of the platters after the read, before it can write them.  So sequential read times are unfortunately not applicable here.  And because it is one long sequential process, the drive cache and OS buffers are not a help here either, as none of their contents are being reused.  Really makes you appreciate the Cache drive...

[SSD]

ack. Well... that kind of sucks.  I suppose the price to pay for data integrity.

 

I'll hook up a cache drive asap

 

Remember that although the write performance is on the slow side, the read performance is not.  unRAID is first and foremost a media server.  The very nature of media is that it is mostly reading.