Defragmenting IBM ServeRAID-4Mx clustered drive

[DaveRyan505]

I'd appreciate advice on defragmenting a shared drive contolled by an IBM ServeRAID-4Mx controller. Microsoft Cluster Administrator is being used. The fragmentation is at 81%, and I need to know the best way to get it defragged.

thanks.

 

[catorze]

Fragmentation occurs when a file is read into memory, then modified where it increases or decreases in size and is then written back to disk. Fragmentation also occurs when files or records within a file are created and then deleted on a regular basis. In general, larger allocation sizes (NTFS Format) reduce fragmentation because the larger allocation unit can fit more stuff before requiring another allocation unit (which in most cases will not be adjacent if the file is aged more than a few minutes for
a busy server). But the down side is a larger allocation unit will have some unused space in the last allocation unit in a file chain which will waste disk space. Since disk space is so cheap this is not usually a concern (except when there are extremely large numbers of small files).

For example: Formatting with a 16KB allocation unit (compared to the 4KB default) and a 32KB stripe size (compared to 8KB default) should reduce the potential for
fragmentation, but it is not likely to have a significant impact on performance for most email servers. The confusion comes from a "end user" mentality - with a desktop system "you" are the only user. "You" tend to
access one file at a time. So if the file is fragmented a head seek has to occur to access the fragmented allocation units. This tends to slow performance. In a server there are hundreds (perhaps thousands) of users, each trying to
read and write data. The server does not allow exclusive use by any one user for more than a few disk operations. Otherwise, one user could "hog" the system for the time it took to load all the mail. If a number of users did this the one at the end of the list could see minutes before getting a response. Furthermore, the application cache (NSF Buffer) will store recently modified records for writes to disk. In this case the disk subsystem will be given a queue of I/O to accomplish for many different
users. The disks will order these I/Os so that they are performed with minimal head movement. However, these I/Os are a collection of I/Os from many users which have mail files distributed across the disk. So the disk will have to move the head anyway on every few disk operations. So you see it does not matter if the files are fragmented because the list of I/Os will never be sequential and elevator seek optimization will always occur.

The only time fragmentation significantly affects performance on an email server would be during backup.

Moral of the story: Don't worry about the fragmentation!

 

[tectone]

Backup is much faster for servers if they are regularly defragmented. Going in for a regular defrag is ideal as it definitely lends to stability and minimizes risks of crashes and freeze ups. The job has been made quite effortless thanks to the number of third party tools that defragment smoothly in the background with no interruptions to file access and system function.