Home   Free Downloads   Product FAQs (NT)   Product FAQs (OpenVMS) Product Alerts   Technical References     Links
	Fragmentation and RAID 2 There is a widely held misconception that RAID devices do not need defragmenting. It's been around for a long, long time, and is still a very common subject in our e-mail and tech support calls. It is so common that we realized we needed to reissue this article. The original can be found at Fragmentation and RAID , the more recent articles are posted at . We have found there is a lot of confusion about fragmentation and how it affects RAID devices. The facts are, RAID devices are subject to fragmentation, do not prevent fragmentation, and do not defragment themselves. And in actual fact, fragmentation degrades stripe set performance more than it degrades single volumes. Here are the facts: RAID originally stood for Redundant Array of Inexpensive Disks; now Inexpensive has been replaced by Independent. They are often referred to as RAID arrays, which is redundant, but useful because Microsoft has an internal-use debugger whose acronym is RAID, so we use the term "RAID array" to avoid confusion. Most RAID devices are RAID-5, and are essentially stripe sets. They fragment just like stripe sets, and are defragmented in the same way. Let's take for an example a RAID array of four physical disks. When data is written to the array, it is written more or less equally to all four devices. This means writing and reading can be almost four times as fast as to a single disk, because all four devices are active simultaneously. If it takes 1000ms (milliseconds) to write a file to a single disk, the same write will take about 250 to 300ms to write to this RAID array. Reads are similarly faster. If the data on one of the disks is in two fragments, the read will not take twice as long, but it will take longer than usual. The read/write head will have to perform an additional seek (seek = movement of the read/write head from where it is to the track where the data is) to get to the second fragment, then you wait for the disk to turn until the data comes under the head. How long this takes depends on the hard disk, but it typically averages about 9ms. The longest time required is the sum of the seek time plus one rotation. The average time is one-half of the longest time. The formula to find the access time for a disk is: Divide RPM by 60 to get the revolutions per second Divide 1000 by the result to get the number of milliseconds to do one revolution Add seek time in milliseconds Divide by 2 to get the average time to get to the data. This is the average extra time required for each excess fragment. The calculation should be done for the disk that has the most fragments for the file, because your time to complete the I/O is limited by your most fragmented disk. If the file in our example above has one extra fragment, it will take about 3% longer to read (about 9ms extra time added to a 250ms read). If it has ten extra fragments (all on the same disk), it will take about 30% longer to read (90ms added to 250ms). Now, look at the same file if it is on a plain single disk partition instead of a stripe set. It takes 1000ms to read, and each fragment adds 9ms. One fragment extends the read time only .9%; ten fragments extends the time only 9%! You see, we are adding the same amount of time in milliseconds whether the file is on a stripe set or not, but the added percentage of time is much worse on a stripe set. Of course, the stripe set figures assume all of the fragmentation is on one disk, but in the real world, fragmentation will be spread across all of the disks. If the fragmentation is spread equally on all disks (best case), the percentage of slowdown will be the same as for a single disk. Any other distribution will be worse. So, at best, the stripe set will be no better off than a single disk. In most cases, the effects of fragmentation will be greater. The properly designed defragmenter such as Diskeeper* will defragment RAID arrays without defeating the striping effect. It does this by treating the segments of the file as separate files. That is, it consolidates all of the fragments on one member disk into one contiguous segment, but it never moves data from one member disk to another.   If you have any comments about this article or any requests for new technical articles e-mail
	Executive Software Europe