You may have heard, somewhere during your career as an NT system
administrator, that RAID devices do not need defragmenting.  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" or "RAID devices".  

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 as 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:

1.  Divide the disk's RPM by 60 to get the revolutions per second.
2.  Divide 1000 by the result to get the number of milliseconds to do one
revolution.
3.  Add the seek time in milliseconds.
4.  Divide the result by 2 to get the average time to get to the data.

This is the average extra time required for each excess fragment for a file.
The calculation should be done for the disk that has the most fragments for
such a 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(r) 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. 

@Macarlo, Inc.
@Macarlo's Shareware & Web
OS/2
Java Lobby Member
Java Site Accredited

[TOP] [HOME] [INDEX]