Host level fragmentation. Releveant on EVA?

[agent006]

We've started using a few TB of FATA storage on our EVA 6000 as D2d backup space. We're seeing horrendous NTFS fragmentation on the 2003 backup server with these volumes.

My natural reaction is to defrag the volumes as i would with local storage, but I'm wondering how relevant this is given the EVA's distributed storage across many disks (24). Will defragging at host level offer me any benefits or am I just wasting time?

[kunalsahoo]

Just to confirm, an EVA knows nothing about the file structure on the Vdisks... That is controlled completely by the operating system, Windows in your case.

Defragmentation has to be done via the OS.

The EVA (or most other Array products) have storage space divided in logical blocks. The Filesystem determines which logical block contains data and which block is part of the filsystem meta data etc. Defragmentation therefore has to be driven by the OS.

Key here is to have anough free space on the volume to allow defragmentation. if the volume has not enough free space the defragger may not work. 25% free space should do it. Operations need to be stopped though during the defrag.

you can also use disk keeper 3rd party toll which has more functionality ...

Cheers

[agent006]

That's my question though. If the EVA knows nothing about the file system, and therefore is putting the data all over the place on plenty of different disks, is there anything to be gained by defragmenting the logical volume?

[kunalsahoo]

yes....as it will affect the os io opearations to the disk....the EVA luns are as good as disks to that OS end of the day !!!

[gabbar]

most of the vendors for disk defrag utils might debate that fragmentation cause severe impact on performance.. but going by my own experience defraging the SAN disk does not improves the performance much especially on arrays with large cache size. you might want to read some unbiased articles

http://sqlblog.com/blogs/linchi_shea/archive/2008/12/07/performance-impact-file-fragmentation-and-san.aspx

[Greybeard]

Fragmentation is hardly relavent on an EVA, all your data is chopped up into 2Mb PSEGs across all the disks in the group containing the Vdisk and is mapped to the files. there is no contiguous file structure on an EVA and windows may be confused by the mapped locations as translated to the EVA's data blocks. A better indication of the volume's health would be to configure EVA perf and windows perfmon to see how the throughput is performing, this should be fairly quick given the number of spindles in the DG.

[Uwe Zessin · Accepted solution]

A virtual disk is chopped up into multiple 8 MByte segments called RSTOREs. An RSTORE (Redundant STORE[*]) is chopped up into 128 KByte chunks(or whatever the EVA internal terminology is) and distributed (together with/out redundancy information) across 4(VRAID-0), 8(VRAID-1), 5(VRAID-5) or 6(VRAID-6) disk drives. A PSEG is used to 'chop up' a disk drive and it does contain all chunks of a particular RSTORE on that disk drive.

[*] Despite the "R"edundant in RSTORE or RSS, no, there is *NO* redundancy for VRAID-0! (some people do beleive that the EVA virtualization implies redundancy)


I do not understand why Windows or any OS should be confused by that mapping. It is completely transparent - the host sees a continuous array of 512 byte blocks.

[Greybeard]

Thanks Uwe, though I was only responding to the defrag issue. Note I said 2Mb (mega bit, not byte) or one FC payload. this i/o pattern is used in the file to block mapping table which win defrag accesses, so yes it sees a continuous but not contiguous file structure. ;~)