Bad performance? Post here!

[Skirge01]

You won't get SMART info in tRAID, but you can get it using something like HD Sentinel.  I use that program to monitor the health of my drives and it has successfully predicted the failure of 3 drives just in the first year I've been using it.  That should mean it's possible for tRAID to get the information, as well, but I guess the implementation is different.  I thought the same thing you did about the spin down of the drives, but I'm not so sure, since I seem to regularly hear my drives spin up.  Personally, I'd prefer that they were always spinning, though.

[Brahim]

@Skirge01
You might just need to set the advanced SMART mappings to get it to work under tRAID.

[johnzered]

@Skirge01
That's good news. Could you try the following command in the advanced mappings in tRAID SMART: "-d sat".

[Skirge01]

@Skirge01
That's good news. Could you try the following command in the advanced mappings in tRAID SMART: "-d sat".

You mean under "Device Type Mapping"?  If so, this is what I received:

ERROR: smartctl takes ONE device name as the final command-line argument.You have provided 2 device names:sat/dev/pd2Use smartctl -h to get a usage summary

Also, how do you undo/change the setting once it is set?  I changed that on a single drive and now the advanced options are greyed out for that device.

[Brahim]

That UI bug is fixed for the next release.

[vletroye]

I am quite lost.... I did create an array two days ago and the mean throughput to create the parity was about 240MB/s.
Concretelly, this speed was 30MB/s during one hour and increased slowly to finally complete at 250MB/s (33 hours)...

In that array, I used to have 8 DRU on one controller and 2 PPU on another controller. (4x2TB + 1TB + 2x3TB of DRU + 2x3TB or PPU)

Both controllers are equivalent, from LSI, same features/characteristic/... except that one is 16 ports (with the DRU) and the other one is 8 ports (with the PPU).

Yesterday, I have deleted my initial configuration and move two disks (DRU) from their controller to the controller with the PPUs. Then, I have created a new array and started the creation of the parity.

Now, the throughput in about 20MB/s and it's running since 19 hours... Only 4% has been completed ?!?!?
This is incredible ?! I have only moved two DRU from a controller to another one ?!

The 10 disks are 100% ok from SMART point of view...

I did benchmark the disks before adding them into the array, with Windows Caching disabled. I had the same mean throughput for all disks intended to be used as DRU, being either on the first controller or on the second controller.

BUT for my ST3000DM01 intended tobe used as PPU, I had >300MB/s for read and ~70MB/s for write...
While for my ST3000DM01 intended to be used as DRU, I had : ~200MB/s for read, ~50MB/s for write...
The only difference, the disk going to become DRU are > 90% full while those going to be used as PPU are empty (empty volume)

I will abort the creation of the parity and move the disks used as DRU back to the first controller.
But is there anything else that I should do/try before re-creating the parity ?

[Brahim]

@vletroye
Beats me.

One thing I plan on doing is creating a database for setup that work well for tRAID.
With some many varying hardware, there is just too many variables to answer performance variances.
It could be so many things including drivers.

[vletroye]

I am figuring that the speed increases depending on how may disks of (various size) are "still" used to compute the parity.

I mean, if one has 5 DRU: 1x1TB + 2x2TB + 2x3TB and 1x3TB PPU, the process is slower when computing the parity that includes the 1TB DRU  than at the end, when the parity is only computed from the remaining space from the 2x3TB DRU. (Am I clear ?)

The speed to compute the parity on a RAID-F was more constant as long as one was using "DRU spanning" to lower the number of DRUs and get DRUs of equivalent size...

Or you have a completely different approach to compute the parity (a secret  ) to avoid this side-effect ?!

V.

[terrastrife]

BUT for my ST3000DM01 intended tobe used as PPU, I had >300MB/s for read and ~70MB/s for write...
While for my ST3000DM01 intended to be used as DRU, I had : ~160MB/s for read, ~50MB/s for write...

There is something completely unrealistic with that PPU disk, no mechanical disk does greater than SATA2 speeds sequentially. Write speeds are also well below the normal. Both disks should be near identical, quite possibly may have physical disk errors.

[vletroye]

And I confirm it's not a SSD... but a 7200RPM... so indeed, it should not reach the throughput of a Sata II interface...
Maybe an issue with Crystal Disk Mark ?


N - ST3000DM01 50MB par vletroye, sur Flickr

Regarding the big difference between the Read and Write, I have not idea if this is normal. But notice that I did disable the Windows Write Caching !


F - ST3000DM01 50MB par vletroye, sur Flickr


G - ST3000DM01 50MB par vletroye, sur Flickr

[vletroye]

In addition to confirm or not that the amount of disks still used to compute the parity impacts the processing speed I am also interested to know if the maximum processing speed is limited by the speed of the slowest disk in the array ?

I presume that it's the case as a bit must be read from each disk to compute and write the related parity...

If this is confirmed, my old 1TB Sata Disk must seriously slow down the whole process (at east as long as this disk is not yet fully processed...)

This 1TB is a Samsung Spinpoint F2 7200RPM with a max Read speed around to 110 MB/s.
My Seagate Barracuda 3TB 7200RPM have a mean Read speed close to 150 MB/s.
My Samsung ecogreen F4EG 5400RPM have a mean Read speed around 140 MB/s.

Removing the 1TB disk should therefore boost the performances of at least 30MB/s. Right ?

V.

[Brahim]

The slowest disk does impact the RAID tasks (Create, Verify, etc.), but not other disks during array usage as the disks are independent.

[vletroye]

Ho, right!

The parity of my array was created in 33 hours for 15TB of DRU* on one controller + 2x3TB of PPU* on another controller, with all default values kept for the t-RAid settings. Mean throughput was 241MB/s.

Next, I did recreate the parity with TCQ enabled (but no other settings changed). Mean throughput again 240MB/s. Processing completed again after 33 hours.

So TCQ didn't change the speed of parity creation...

I wonder how faster would be the "create" (and later the "Verify" - which will be done often - and therefore matters) if I remove now my slowest disk. I think I give it a try for testing purpose



V.

* 1x Samsung SpinPoint F1 HD103UJ 1 TB, 4x Samsung EcoGreen F4 HD204UI 2TB, 2x Seagate Barracuda ST3000DM001 3TB
** 2x Seagate Barracuda ST3000DM001 3TB

[terrastrife]

I have a bit of a 'weird' performance going on. The 4TB disk is just, slower for some reason. I went and tested the disk back in windows and it was reading and writing (transferring files) >150MB/sec with no problems. The two 3TB disks are in the same enclosure sharing a SATA PM and USB3 bridge, the 4TB is on the ICH10R.
Oh well, I'll let it complete and see how things go.
I am adding UoR's to the array.

[vletroye]

the disk back in windows and it was reading and writing (transferring files) > 150MB/sec with no problems

150MB/sec is not that fast... I guess that your 3TB are faster ?!

Look on the web for reviews of your 4TB and 3TB disks... You will possibly find that the 4TB is indeed slower than the 3TB for sequencial read/write. It's what I have discovered about my own disks...

So, based on the disk perf, I decided to replace a 1TB disk with a 3TB disk in my array. And now, to create the Parity of this array (which is 2TB larger than before), it takes 30' less than before !!!