Storage Area Networks (SANs) are becoming increasingly more common. A few years ago “SAN” was an acronym that rarely made it out of the lexicon of IT Storage Admins at 1000s+ employee multinationals. In more recent years the SAN IHV/ISVs have greatly simplified and reduced the installation, maintenance, technical effort, and acquisition costs. It’s increasingly more common to see SANs in medium sized businesses. Many SAN providers have even offered targeted “mid-range” solutions often for those mid-sized organizations. EMC is one such vendor that targets just such a solution with their Clariion product line.

Microsoft has also been at the forefront of advancements in data storage centralization. Technologies like Storport (introduced in Windows Server 2003), iSCSI software initiator, multipath I/O storage stack, and more.

A great deal of innovative software from Microsoft and SAN vendors make the whole system work.

An important point to be aware of is where in the whole computer system, the SAN “plugs” in. A SAN is, in essence, a replacement for a single disk. In the Windows I/O storage stack a SAN solution replaces the disk driver (disk.sys), with its own drivers. Eventually data must reside on a physical storage device of some kind, so any request to read or write data will have to go through this disk driver, or SAN replacement thereof. However, before the I/O request gets to this lower level it goes through a local disk file system. When talking about Windows in a SAN, that local disk file system is pretty much always going to be NTFS. Fragmentation as Windows sees it and cares (same for Diskeeper), is at NTFS. So, if files are fragmented as NTFS sees it, the local disk file system has to send a great deal more I/O traffic into the SAN, causing the SAN to do more work that it should.

We have a very thorough white paper that covers defragmenting SAN. It also includes Best Practices for Diskeeper. Check it out here.

Even SAN vendors recommend defragmenting Windows. EMC includes a paragraph about the need for their Clariion family of products in a white paper (emc.com collateral hardware white-papers h711-emc-bu-stor-ibm-tivoli-ldv – link missing). In it (pg. 5) it says:

“File system fragmentation over time is almost inevitable. Performing defragmentation regularly keeps performance optimal. There are a number of host-based utilities that can perform defragmentation in place to accomplish this… (SnapView™, SAN Copy™ and LUN Migration will not defragment file systems)…” … “Perform regular defragmentation of the file system to ensure optimal performance.”

The interesting part is they also note the SAN file system solutions they offer are NOT designed to handle NTFS fragmentation, and that they recommend to defragment that “local disk” file system. When we here at Diskeeper talk about the need to defrag SAN attached systems, were talking about doing what we always have done – defragging NTFS in Windows (from Windows). That is an important point as SANs also use a file system to organize data. Diskeeper, nor Windows defrag addresses this. “If” defrag of some kind is needed in this SAN file system it is handled by the SAN vendor – you can check with their support staff on that subject. Defragmenting NTFS and defrag of SAN file systems are two completely different subjects and should not be confused.

Even more reading:

Ziff Davis Enterprise (from the same parent company of eWeek) just released a paper on defragmenting SANs, including benefits and covering some considerations as well. You can read that here.

In summary, even with the tremendous amount of technology that has gone into SANs over the past decade, defragmenting SANs is still just as vital as defragmenting DAS (direct attached storage).