On Tue, 13 Apr 2004, Christopher Petrilli wrote:Hello All.
2. Retrieval time is limited not by disk bandwidth, but by I/O seek performance. More spindles = more concurrent I/O in flight. Also, this is where SCSI takes a massive lead with tag-command-queuing.
In our case, we ended up using a three-tier directory structure, so that we could manage the number of files per directory, and then because load was relatively even across the top 20 "directories", we split them onto 5 spindle-pairs (i.e. RAID-1). This is a place where RAID-5 is your enemy. RAID-1, when implemented with read-balancing, is a substantial performance increase.
Please explain why RAID 5 is so bad here. I would think that on a not very heavily updated fs, RAID-5 would be the functional equivalent of a RAID 0 array with one fewer disks, wouldn't it? Or is RAID 0 also a bad idea (other than the unreliability of it) because it only puts the data on one spindle, unlike RAID-1 which puts it on many.
In that case >2 drive RAID 1 setups might be a huge win. The linux kernel certainly supports them, and I think some RAID cards do too.
Just wondering.
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
I'll try to explain the raid scheme
First of all the head movement takes 99% of all data retrival time in case you would like to get a small block of data (actualy one FS block).
You need to move HDD's heads something like 4-20ms when reading of a block of data (actualy one cilinder will hit hte disk's cache) takes 1000 times less time.
Now to the RAIDs:
It is true that the only RAID that allow increasing of record speed is RAID0. That is why all database developers recomend RAID0+1 or RAID 10 (They are different, but it is not the topic here). So if you need record speed - you know the way.
At most all RAIDs give you a read performance goal. The matter is when RAID5 is slower than RAID1 (whatever else) is the matter of disk subsystem planning and configuration.
If you have the FS block size is 4K, then all disk IO from the OS point of view is reading 4k blocks.
While in the RAID you could have a block size configured to 4,8,16,32,64,128k.
Lets imagine three situations:
1. Raid bock size is 4k and we have 3 disks in RAID5
The controller will read data by blocks, so it could get 2 blocks at a time (3rd disk stores redundancy information). The situation is exactly like when using RAID1 with 2 disks.
2. Raid block is 128k, and we have 3 disks in the RAID5
The controller will read the whole block even if you have asked to read only 4k (and you did, because of FS request size). And as you could see 124k will hit cache but will be useless.
But if you have files that of comparable size with the block or much more in size than a block you will increase reading performance drammaticaly (like for video files which were put on the disks contineously and are being read block by block).
So, if you have some time try to "play" with your raid 5 and you will see the differences when you change block size of you FS or RAID's stripe size. But you will see that single disk writes data always faster than RAID 5.
If you are talking about software raid (supported by the kernel) - it will be always slower than hardware one (you will loose at least 30% of your system bus and CPU power for calculations and internal RAID5 data computing). With RAID 0/1 it is not so drammatical but remember that you have RAID1 support in the kernel not for the productivity improvement of IO but for redundancy. And software raids does not decrease your system downtime.
-- Best regads, Anton Nikiforov
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
