[Info-vax] backup /image on Windows or Unix?

[Keith Parris]

On 1/23/2013 8:46 AM, Jan-Erik Soderholm wrote:
> Jan-Erik Soderholm wrote 2013-01-23 16:35:
> I have never defragmented any VMS disk, or anyway, not in the
> last 10-15 years. Current prod system has system and data disks
> initiated in 1998 and 1999. DFU reports:
>
> Syst disk: File fragmentation index: 7.526  (poor)
> Data disk: File fragmentation index: 1.310  (good)
>
> (I have no idea how *that* is calculated either... :-) )
>
> I guess that could be improved anyway.
>
> Anyway, with today's storage systems, the whole idea of
> defragmentation has lost most of it's meaning, I'd say.
> There is some overhead with reading extentions, but most
> of the additional disk-head latency isn't there anymore.

In studying large OpenVMS cluster environments, the place where I tend 
to find disk fragmentation gets people into performance problems is 
typically more related to locking than to disk seek time.

In addition to the many fragments (extents) on disk, a fragmented file 
has many retrieval pointers; only so many of those (between 38 and 77) 
can fit into a single file header. Large fragmented files will thus have 
many extension file headers. This may tend to abuse your ACP file header 
cache, and cause locking delays as well.

Disk subsystems like the EVA allow you to spread disk seeks across many 
spindles in parallel, minimizing contention for disk heads, and allowing 
more seeks to be done at once. That can help with split I/Os and 
retrieving the extension file headers scattered all over the index file 
if they aren't found in the ACP_HDRCACHE area. But split I/Os are only 
one of the detrimental effects of disk fragmentation.

While you're opening that file, or doing a window turn, or adding more 
space to the file, you have to hold the file serialization lock to 
prevent someone else from changing a file header while you're looking at 
them. That results in lock queues on file serialization locks for 
fragmented files.

I've even heard of a case where a file became so fragmented (with more 
than 18K extension file headers) that OpenVMS ran out of resources and 
crashed trying to open it. That's an extreme case, obviously.