I have just implemented a file server with a RAID-5 array (four spanned drives, total capacity equal to three drives with 1/4 of each drive storing redundant parity informaiton, RAID is all handled in the hardware controller).

I am using the NTFS file system on this RAID array. Significant thrashing will occur (files of varying sizes will be constantly added and removed in willy-nilly fashion).

Must this RAID drive be defragmented regularly?

The only reason I ask is because the OS sees only a "virtual" drive from the RAID controller. I don't see how a third-party defragmenter could do any good in this situation. Is my hunch correct?

Defragging will still help in this situation or any other raid solution.

The begining of that virtual drive is going to be physicially located on the begining of each drive, and (assuming all the drives are the same size) the end of the virtual drive will be on the ends of the physical drives. So, even though the drive the OS sees is not real, it still works like a real drive. It will take longer for the array controller to move the heads all over the drives to grab data instead of in a sequental pattern, just like normal drives.

I thought that one of the advantages of NTFS was that you didn't have to defrag it?

I thought that one of the advantages of NTFS was that you didn't have to defrag it?

Yeah, and it'd be cool if there really was a Santa Claus, too. But the fact is, despite what Microsoft and your Mommy told you, NTFS can get fragmented just like FAT can.

And thanks for the information, Drakino. We'll be using Diskeeper.

Ah,
Another victim of Microsoft Hype.

Yes, MS used to say that NTFS did not need to be defragged,
[in fact MS did not even include the APIs in Windows NT to allow 3rd parties to defrag NTFS filesystems].

But in more recent time they have conceded that NTFS needs it on a regular basis - this is in part a inherrent design limitation of the filesystem since it was based in part on the VMS Operating System and its filesystem structure.

Hence their inclusion of the Defrag utility in Windows 2K [and Windows XP.

More to the point - you should generally not fill a NTFS volume beyond about 50% capacity as you see quite dramatic slowdowns once you go beyond 50% full on NTFS volumes.
This is due to the fact that NTFS leaves deliberate file growth gaps when the drive is being filled up with data.
By the time 50% full is reached NTFS then begins to fill in the gaps it left, reducing the room for existing files to grow contiguously amoungst other performance problems.

How well a defrag utility will work on a RAID 5 disk volume I am not sure having never tried it.

I can suggest that it will generally be a slow process as RAID5 disks are optimised for more reading than writing [since the parity calculation and then striping of parity across multiple platters take time] and as a Defrag involves lots of writing to move stuff around you may find it something you do over a long weekend once in a while rather than a regular thing.

BTW: For those who are interested there is a small VBscript file you can obtain that lets you run an unattended disk defrag using the inbuilt W2K/XP defrag utility which is normally interactive only. This can save the need to buy a unattended disk defrag tool as NT already has everything needed to do this.

...there is a small VBscript file you can obtain that lets you run an unattended disk defrag using the inbuilt W2K/XP defrag utility which is normally interactive only.

Is it the one mentioned here?
Or some other gem?

/Michael

No the example I've seen uses vbscript to invoke the dfrgntfs.dll [via COM], then invokes the defrag method on the com object.

While either approach is valid, I think I prefer the COM approach as it allows other people to embed it into their code e.g. via a VB program.

I'll see if I can dig up the script [its on one of the PCs at work that one of our employees uses].

I can suggest that it will generally be a slow process as RAID5 disks are optimised for more reading than writing [since the parity calculation and then striping of parity across multiple platters take time]

Just to be pedantic, you forgot the fact that the system also has to read in other blocks when writing. That is, the interleave size of RAID5 is usually larger than a disk block, so when a disk block is updated, the system first has to read in the rest of the interleave set before it can even calculate the correct parity. I hear some more intelligent ones will read in the related parity and calculate it off of the old and new blocks instead of the entire set, but AFAIK, that's fairly uncommon, and it still requires yet another read. Regardless, you're right; RAID5 is slow to write.