Disk defragmentation and Fast VP

Lars, are you referring to System Center Operations Manager when you say "SCOM"?  Because if so, I think there's been some misinformation.

SCOM is a monitoring system at its heart.  It does not schedule things like deframentation on monitored hosts.  That's not to say that an Administrator could not set something up that would do this ... but then it's more about actually running Defrag than it is about SCOM.

As for the effect of running a Defrag - this is about how allocations will occur within the filesystem, and in the case of DeFrag, one of it's behaviors is to move files around within the filesystem to make them contiguous.  The problem here is that if a file is in multiple fragments, these fragments already exist in allocations that have come from the filesystem, and thus consume space from the VP pool.  If the fragments are moved by the defragmentation, then they will typically be moved to a new location within the filesystem.  This new location *may* end up being previously un-written.  If that is the case, then you will end up doubling this allocation.  If that happens a lot, then more and more of the LUN allocation will occur, but you will see that NTFS allocation remains flat.

But the result will not be deterministic.  Running defrag against a filesystem that has no fragmentation will not do much.  Filesystems that support a small number of large files, like those for SQL Server DBs should not be defragmented, since there's no real value in doing this.

FastCache behavior will be more interesting.  Remember that FastCache doesn't care *why* the I/O occured, just that it occured.  So the I/O resulting from DeFragmentation will have an effect on Fast Cache behavior in the same way that any other I/O would.  It's probably not valid to consider this I/O as being representative of I/O being used for FastCache analysis.

The point being, that unless there's a real value proposition for defragmenting a filesystem ... don't.  Most large file allocations will not see any significant benefits from it (think SQL, SharePoint, Exchange). General purpose fileshares might be candidates.

And if you do, don't do it during normal work time periods.

TX

I guess that this is what mu customer is refering to:

http://thoughtsonopsmgr.blogspot.com/2011/06/logical-disk-fragmentation-level.html

It seems that he has this scheduled defrag of the OS disk set to on for all his windows servers.

Would EMC advice against that?

LarsB

Lars, yes, in general, EMC would not recommend running defrag operations on thin devices.

But I will be the first to admit that is a very broad statement.  Some of the points raised in that article do raise the same issues that we would in this area.  Defragmenting, while a valid operation to do on a laptop hard drive, or internal drive for a server, doesn't often make sense in a SAN environment.  In the case of Thin Pools, it also brings some negative side-effects that customers may not like, including a whole lot more space being allocated from a pool, for very little positive return.

For every rule there will always be exceptions.  My guidance would be that you should always treat this process as an exception rather than the rule.

Also, in another very broad statement, for a thin pool we like to have data distributed across all the data devices. This will happen naturally as the pool is used. It will also happen as someone attempt to defragment a filesystem. So in some cases, what the administrator may think he or she is acheiving, isn't actually happening at all.  There is the allocation unit size of the volume to consider with respect to pool allocation unit size ... but that's a more complicated discussion to get into on another day.

Lars,

Here is overall of Defrag with VNX Luns.

Server (OS level) Defragmentation:

1. Thin LUNs do not benefit from system defragmentation
2. Could result in compaction of data that was previously widely distributed across multiple private RAID groups
3. Thick LUNs may receive some benefit

therefore, to your questions,

Defrag would not provide additional perf improve on FAST, even with some negative.

Eddy

Hi Lars

Check the VNX Best Practice doc re defragmentation, some info below

...also just to add, with FAST VP we are often best using on a Storage Pool used for data, OS Volumes can be seperated to a non FAST VP enabled Pool and we then have the option to exclude from FAST Cache.

EMC Unified Storage Best Practices for Performance and Availability: Common Platform and Block Storage 31.5

Document is located on Powerlink here:

Home > Products > Hardware/Platforms > VNX Family > White Papers

...

Host file-system fragmentation

When the percentage of storage capacity utilization is high, file system defragmentation of host storage can improve performance.

• File system defragmenting is not recommended for the following:Virtual Provisioning pool-based LUNs, including FAST tiered pools, and compressed LUNs
• Traditional LUNs bound on flash drive provisioned RAID groups
• Any LUNs that are using the FAST Cache feature

The following sections describe the recommendations for file system defragmentation.

Mechanical hard drive-based storage

Storage using traditional LUNs on mechanical hard drives benefits from host file defragmentation.

A fragmented file system decreases storage system throughput by preventing sequential reads and writes.  In a fragmented file system with LUNs hosted on RAID groups provisioned with mechanical hard drives seek more frequently and over a larger portion of the drive than they would if the data were located contiguously on the drive.  In general, the longer a file system is in use, the more fragmented it becomes. 

Fragmentation noticeably degrades performance when the hard drive’s capacity starts to exceed 80 percent.  In this case, there is likely to be difficulty finding contiguous drive space for writes without breaking them up into smaller fragments. 

It is important to monitor the fragmentation state of the file system.  You should regularly defragment the file system hosted on traditional LUNs with defragmentation tools appropriate to the file system.  Defragmentation should always be performed during periods of low storage system activity.

Defragmentation tools

EMC does not recommend any specific defragmentation tool.  File-system fragmentation occurs independently of the operation of the storage system.  The actions of any defrag tool are simply treated as I/O by the storage system.

Before using any defragmentation tool it is prudent to perform a full backup to ensure the safety of the file system.  An effective alternative method to tool-based file-system defragmenting is to perform a file-level copy to another LUN, or by executing a backup and restore of the file system.

Defragmentation exceptions

Pool-based LUNs, flash drive-based LUNs, FAST VP LUNs, and FAST Cached LUNs do not benefit from file system defragmentation the way traditional LUNs do. 

Pool-based LUNs

Thin LUNs should not be defragmented.  A pool’s allocation algorithms are such that defragmentation of files does not guarantee an increase in available pool capacity or performance.  Thick LUNs may receive some benefit. 

Thick LUNs reserve their capacity within the pool.  Allocation of thick LUN capacity happens on demand.  Because of this, there is the potential for some benefit in defragmenting them. More heavily fragmented thick LUNs with a high percentage of their capacity already allocated benefit the most. 

It is inadvisable to defragment thin LUNs.  Defragmenting a thin LUN may reclaim space for the file system, but it does not return that capacity to the pool, just to the file system.  The potential performance benefit of file consolidation also may not be realized. The defragmented files will likely not result in an optimal re-organization within the pool’s storage.  The highest pool performance comes when data is widely distributed across the pool’s RAID groups.  A thin LUN defragmentation may compact data that was previously widely distributed into a small portion of a smaller number of private RAID groups.  This reduces overall pool performance.

When supported by the host O/S, you can shrink a host LUN to reclaim the defragmented file system capacity for the pool.  LUN shrinks should only be used when severely fragmented pool LUNs have been defragmented.  This is because a LUN shrink cannot reduce capacity below 50 percent of the original LUN’s capacity.

Flash drive-based storage

LUNs hosted on flash drives do not benefit from file system defragmentation.  Flash drives are random access devices.  There is no advantage in a sequential organization of their LBAs.

FAST VP and FAST Cache-based storage

Pools implementing the FAST VP feature or supported by FAST Cache should not be defragmented.  Defragmentation makes assumptions about the physical layout and physical locality of data based on the file system’s logical locality.  This assumption is not correct within a tiered pool or a pool supported by a secondary cache.  Depending on the file system’s allocation granularity, the operation of the defragmentation may have an adverse effect on performance.  Granularity is the capacity being internally buffered.  Changing the previously algorithmically selected contents of the tiers or in the secondary cache degrades their performance.  A defragmentation can undo the effects of a FAST Cache or FAST VP feature’s warm-up.  A small granularity, for example 4 KB, will result in changes that may require re-warming the tiers or cache.  Note that 4KB and 8K the most common file system sizes. 

Note

Host volume shrink

A host file system defragmentation should be performed before a traditional or pool-based LUN shrink to consolidate the LUN’s capacity.  This should take place before the host-volume shrink.  A file system defragmentation yields the largest amount of capacity from the traditional or thick LUN that can be shrunk.

Pool-based LUN considerations

A pool-LUN file system defragmentation may be needed for the host-side, when a substantial amount of the capacity is being shrunk.  Generally, it is not recommended to do file system defragmentation of Virtual Provisioning pool-based LUNs.  However, Pool-LUN capacity that was previously consumed, and host reported usage of LBAs need to align for the shrink to complete.  Note defragging the pool-based LUN may have an adverse effect on cache and backend performance.  Try to omit defragging.  Perform the host-volume shrink without a prior defragmentation first, to see if acceptable results are yielded.

Fixed files

Lars,

you may be interested to check out these threads discussing defrag on EMC array posted earlier.

sk in defrag

https://community.emc.com/message/404788#404788

defragmenting RAID groups

https://community.emc.com/message/407559#407559

CX3-40 Defrag Concerns

https://community.emc.com/message/407321#407321