System check and harddisk/raid speed tests in a nutshell
A collection of useful commands for inventory and speed tests
Part I: Inventory
Oftenly people complain about low transfer speeds to their OMV box. This is not always a problem of network drivers, cabling or switching hardware, protocols or client OS versions. If the internal transfer speed of your box is slow then network transfer speed cannot be fast.
So I thought it would be a good idea to collect system check and testing commands to check what is going on inside your box as a point to start with if you are experiencing slow transfer speeds. This can help the users to gain information about her system and delivers information for the supporters.
There's a lot of information stored in this forum but they are widespread and sometimes hard to find.
Ok, let's start with a system inventory. I've tested all these commands on my home box with an Asus ITX board, look at my footer for more details.
If you know what the OMV system (Or to be more precise: The Linux kernel) detects in your system you can compare that to what your hardware should be capable of and find differences. And you can make sure that the correct kernel driver is loaded for the appropriate hardware.
1. Hardware oversight
For this we need the lspci command, a part of the pciutils suite. It is not installed by default, you can install it with apt-get install pciutils. The command without parameters deliver a first oversight, to go into detail we use one of the verbose levels. Because it delivers a lot of information you cannot see completely on the screen it is a good idea to send the output into a file with lspci -v > lspciout.txt and so you have all the information in one file.
The first one lspci -v of the verbose levels delivers much more details (To go deeper you can use -vv or -vvv). Of interest are the informations about the harddisk controllers:
Ok, this board has five SATA ports, they are completely detected and running in AHCI mode and the ahci kernel driver is loaded.
For compatibility purposes the PATA drivers are loaded as well:
If your board has SATA ports and is AHCI-capable but the ahci kernel driver is not loaded than the onboard controller was probably not detected correctly due to sometimes exotic hardware. Try to install the backport kernels.
2. Detect the SATA levels
Allright, let's do the next check: Detect the SATA level for every single harddisk and it's port. You need the "system names" like sda, sdb and so on to do this, they can be found in the web-gui under storage/physical disks.
We use the command hdparm -I /dev/sda | grep -i speed and get that:
The output shows that this harddisk is capable of SATA-III from the board port up to the disk.
The same for sdb in my system shows that:
Aha - a difference, the maximum is only SATA-II even it is connected to an eSATA port which is SATA-III capable as well. But the disk (2,5" notebook disk for the OS) is only SATA-II capable so this is correct.
If your system can deliver Gen3 signaling (Aka SATA-III) and your harddisks are SATA-III ones but the output does not spit out Gen3 signaling, check if your controller is detected correctly and check your SATA cabling. Old SATA cables are sometimes not SATA-III ready or they become scrappy over the years.
3. Harddisk details and SATA connections
Next we check if the harddisks are detected correctly with egrep 'ata[0-9]\.|SATA link up' /var/log/dmesg:
Oh, that showed a possible cabling problem in my system. Ata1.00 is connected to the same SATA ports on the board like ata3.00 to ata6.00, but the output says that it is limited to UDMA/33 due to a bad cable. In fact I use a different cable for this disk because it is mounted in a 5,25" bay on top of the front and the brand new yellow SATA-III cables I used for the other data disks are too short, so I used an old cable laying around. Hm.
But Ata1.01 (The OS disk connected to an eSATA port) shows the same and due to the fact that these two disks are obviously connected to the same port group on the board (both ata1. and there was no ata2. found) I came to the conclusion that the board maker has used a port multiplier with different capabilities as the other four SATA ports and they seem to run on PATA-mode (A 40-wire cable is an old style flat cable). Another difference shows that: The two disks (ata1.00 and ata1.01) do not use the AA mode.
This can be a problem if the speed differs a lot from the other disks, but in my case it doesn't. This disk delivers the same transfer speeds as the other ones.
Also important is to look if all the disks are using NCQ (Native command queuing) - if one does not, all the other disks would slow down to the speed of that one. AA is the SATA auto activate mode. I haven't encountered any problems yet, but found some postings on the web reading that missing AA mode can lead to failures in sleep mode (Actually I do not use sleep mode).
That's a first oversight of the system.