Defragging: Why bother?

The biggest “myth” on the common list of myths about defragmentation -- that “I don’t really need to defrag” -- is not a myth at all. No self-respecting propeller-head would ever tell you that you don’t need to defrag.

Especially in the Windows world, data stored in large files isn’t always written on contiguous sectors of a storage medium. When a file is written across multiple disk geographies, it takes longer to write and to read, and that reduces overall performance.

That means increased costs and reduced productivity from disk fragmentation can be significant, especially if you buy new hardware before you really should because you think that will speed things up.

The first line of defense on the defrag front is prevention. I generally prevent disk fragmentation three ways:

1. Keep system files and data files on separate spindles.
2. Dedicate databases and other disk-intensive applications to different sets of disks.
3. Reduce the overall size of data shares.
   

Keeping system files on separate physical disks isn’t a big deal these days. Most of us save files in a portal or on a network share.

But if your user-shares reside on the C: drive of one of your Active Directory Domain Controllers, you have a problem. A single fragmented file in a user data store can affect a large number of users, but fragmentation on the server C: drive reduces the entire system’s performance to a crawl. If your user data fills your Windows server C: drive, you have an emergency on your hands.

Exchange server data and SQL databases should reside on virtualized storage, such as a fibre channel or iSCSI SAN. If your mail and database files are on server-attached storage, keep them off your C: drive.

I’m also a fan of managing the virtual memory page file. By default, even in Server 2008, the default pagefile.sys is stored on the C: drive, configured to double in size “as needed.” By the time the server is loaded down enough to require page file expansion, odds that the file will be stored on contiguous sectors are slim.

We used to build terminal servers with dedicated swap volumes (4M block size, 5GB NTFS for a 4GB swap file). That server could swap to it heart’s content, never fragmenting or using valuable C: drive storage space.

Now we know that swapping is bad and, as they say, “RAM is cheap”. Is 2GB enough swap space for you? Probably – but that’s a topic for another day.

With robust services like Microsoft NFS and Novell Storage Manager, all of your storage can be presented easily and logically in a single namespace, and end-users will never know the difference. With this setup, a larger number of smaller data stores reduce the overall impact of fragmentation. All forms of disk maintenance, from defragmenting to chkdisk, run faster, because the disk being maintained is small.

So, what does fragmentation impact? Performance, budget, and availability.

Performance seems obvious (Google it, if you still need convincing). Opt for a third-party solution, and the impact on your budget can be substantial. Still, you can find products that manage disk writes, defragmenting on the fly, at a variety of price points.

Downtime? You bet. If you don’t prevent fragmentation, or address it proactively and regularly, you’ll have to take a server down for a defrag operation.

Finally, is native defrag – the program in your Windows bundle – enough?

The latest Windows packages come with improved technologies. But Windows disk defrag is, at best, reactive, not preventative. I use Notepad on a regular basis, just not to edit Word documents. Third party products that provide a management console, proactive and regular defragmentation, and control writes to minimize fragmentation may be appropriate for you, depending on the size of your enterprise.

But you CAN avoid high, third-party costs, with good design, effective maintenance, and some good ol’ plain, common sense.

Bottom Line: No matter how you do it – defrag.

C/D/H can help you adopt an overall disk maintenance regimen that will keep you running at peak performance with minimal cost over the long term.