but NOT as a general average speed

 

Completely agree, especially because we tend to fill up ours disks evenly and then spend most of the time writing to the inner tracks.

 

I have a question about the buffering to RAM, I once tried in one of my server going from 4 to 16GB of RAM and didn’t notice any difference in the amount of buffering, Unraid only buffered the first 1 or 2GB.

If you look at the screen I posted above, I’m coping a 8.83Gb file to a server with 8Gb of RAM, 5 dockers, no VMs, Unraid shows about 5.8GB cached RAM witch I assume is available, and I only get the 1 to 2 GB buffer, is there any setting to use all the RAM as buffer?

Read about the disk tunables (Disk Settings).  The md_write_limit parameter sets how many 4k stripes the system can use for buffering writes.    With large amounts of memory you can make this VERY large.

 

Here's an example of a system with 48GB of RAM that gets 113MB/s writes as long as he's writing less than what can be buffered in RAM:  http://lime-technology.com/forum/index.php?topic=40633.msg383837#msg383837

 

By the way, recognize that if you have a LARGE amount of memory and a relatively large write is buffered, it wil be several minutes after the write has "finished" before it's actually written to the array disks => so be CERTAIN you have a UPS !!  If the "real" rate is 40MB/s, that's about 2.4GB/minute ... so if you're got 24GB buffered it will be ten minutes before the actual write to the array completes, even though it will "appear" to have already been done.

 

... his PCI controller and/or his drives were the limiting factor, not his motherboard.

 

Definitely agree => the old, low areal density disks in particular in this case.

 

Okay...  So I have some slow drives, apparently.

 

I presume that they won't slow down operations on the array that don't involve them?  (So, parity sync will be slower, read and write to these drives may be slower, but read/write to other drives should be "full speed for those drives")

 

Is that right?

 

Thanks,

 

Russell

Yes, that's correct => the key slowdown will be in parity sync, parity check, and drive rebuild operations.

 

Write speed to a drive depends on the speed of the drive you're writing to and your parity drive.    For example, right now your parity drive is an 800MB/platter drive, but you have some 1TB/platter drives in the system.  Since both are 7200rpm units, the parity drive is slowing down the writes to the Seagate 3TB drives.  [Not by a lot, as the Hitachi's are still nice drives ... but if the parity drive was a 1TB/platter drive you'd have slightly better performance.]

 

Reads will be at "full speed" for all of your drives (limited by your network for drives that can exceed 120MB/s).    Writes are limited by both the speed of the drives and the fact that a write requires 4 disk I/O's.

 

 

 

 

Gary,

 

You had me ad 120MB/sec reads.  Gosh I hope so...  That'd be awesome.

 

Parity Sync will take a while, rebuilding since I took the two 1.5TB's out.

 

Russell

To be clear, a Gb network is unlikely to achieve its theoretical max ... but I often seen read speeds in the 105-110MB/s range.

 

I have an unRAID test box with a SuperMicro C2SEE, Core 2 Quad, 8GB of RAM and I get 60Mb/s+, however, I only have a few Hitachi 2TB 7200rpm drives in it.

 

Post a screenshot of the Web GUI for your test box that shows your specific drive configuration.

 

 

I finally got around to messing with this.  You were right, with a default config, it wasn't 60+, but in most of my tests it was 50-55.

 

 

 

 

 

This was with Turbo Writes enabled: