Defragger salesman frags HP
'You need my stuff, don't listen to them,' shouts man
Magic Quadrant for Enterprise Backup/Recovery
Defrag software supplier Diskeeper has denounced HP for failing to mention fragmentation issues.
Mandeep Birdi, a technical presales consultant at Diskeeper Corp Europe, said: "It's unfortunately becoming a little too common for me to hear from many customers who are adding SANs to their network estate, that their SAN vendor has either told them not to worry about fragmentation, or didn't even mention it as a possible problem."
That did not endear him to HP, which was keen to correct any misapprehensions here.
HP's response
HP contributed this statement:
Firstly, fragmentation is not an issue for the Enterprise Virtual Array (EVA) and HP simply would not be "forgetting" to inform our customers if there was one.A fundamental pillar of the EVA's virtualisation capabilities is the equal distribution of data blocks across all disk drives in a disk group to provide equal access time for random I/O patterns – which typically can be found in fragmented file systems.
A defragmentation application, such as the one your message referenced, provides a contiguous file reappearance to previously fragmented file systems.
There is no fragmentation issue for the EVA at all
This works well with the EVA platform – just as with other platforms or LUNs in general. Under certain I/O patterns, especially sequential read operations (often appearing with backups), the EVA's read-ahead caching algorithms support a significantly increased I/O performance.
These read-ahead algorithms predict the next disk blocks the server is likely to access based on past access patterns and loads them into cache without having to re-position the MR head. This becomes even quicker when the next data block is adjacent to the previous one – ie, the exact target of a defragmenter.
Over time and depending on the I/O patterns and the operating system, data "containers" will show fragmentation. For sequential data accesses, defragmentation can help to increase performance – especially when combined with sophisticated techniques that the EVA provides.
Also, it is important to note that fragmentation is not caused by the underlying storage system but by the operating systems utilising it. The single HDD used with Windows OS in PCs is a perfect example of it.
In other words, due to the underlying inherent EVA virtualisation, EVA supports equally fast access times for random I/O patterns. Which is not something "traditional" arrays can provide easily. And secondly, for less fragmented environments, the EVA caching mechanisms further increase the I/O performance.
We do want to make it clear that there is no fragmentation issue for the EVA at all and neither do we "fail to mention" it to customers.
So there.
The defrag topic was recently discussed in further detail here.
Some might think that for minnow Diskeeper to accuse a large vendor like HP of misleading customers when there isn't really an issue is a cheap shot aimed at trying to generate free publicity for a product. We couldn't possibly comment... ®
COMMENTS
Dinosaurs?
"the need on Windows went the way of the dinosaurs when all Windows varieties moved to NTFS."
Er, bollocks!
You'll be delighted to hear than that a crufty windows box gets a honking speed hike from a good defrag, both online and (key here) offline for the metadata and registry hives.
Not too long ago, when filesystems on physical disks was the norm, we used to have to defrag our HP-UX boxes to maintain I/O performance. It's only the advent of the SAN arrays that's put paid to this.
Anything storing data to a filesystem on a single disk will benefit from defragmentation as ensuring that the actuator gets its blocks sequentially when reading a given file without having to move around all over the platter speeds up things no end.
Once you use a disk array that supports parallel access, the situation changes. For example, the good old IBM System/38 used to quite deliberately fragment data across all the disks it had available in a given storage pool and returned very respectable I/O performance at the time as a result, so this is nothing new.
NB: Your cheapshit RAID 0 array doesn't cut it here as that also benefits from a defrag. Reading block 1 from disk 1, block 1 from disk 2, block2 from disk 1 (etc ad nauseam) is still faster than having the heads hop all over the shop on all the disks. However, a fragmented RAID 0 setup will often outperform a defragmented single disk purely due to the benefits of parallel I/O.
In order to see no performance degradation from fragmentation you need a controller that supports I/O queuing, out-of-order reads/writes and "knows" where each data block is on any given disk without having to look it up from same. Then it can queue the read/write requests for a disk and satisfy them all with one pass of the actuator across the platters, much like Novell's old hashing and disk I/O elevator algorithms.
I'll just buy a drink for that nice dinosaur at the end of the bar now.
The number one reason NOT to use Diskkeeper...
...is that it is owned and run by a bunch of Scientolgist, who like force employees to take training in their cult.
Sorry to disagree, but
Windows XP on NTFS still needed defragmenting. Badly.
I'm experimenting Win7 now, and I think it may be less important, but I still defrag my disks every month under the principle of precaution.
IT infrastructure monitoring strategies
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
Data control in the cloud
Cloud based data management
Enabling efficient data center monitoring
