On 20 okt 2010, at 20:11, Hart, Charles A wrote:

> Dumb statement, but isn't the whole Idea of the File Devclass is it is 
> sequential.  Can one be more sequential than the other?  If its not then its 
> random.
> 

It is. But, if the blocks that make up a devtype file volume are scattered all 
over your disk, they don't occupy a sequential series of blocks on the disk. 
This means that the disk controller will not be able to do cache read-ahead 
predictions, reducing performance to random-I/O rather that sequential I/O. 
This is even true on LUNs provisioned by XIV or SVC or other smart controllers. 
We even noticed that both TSM and SVC performance increased when the LUNs were 
on sequential volumes rather that striped volumes.

Now, to go back to my original statement, because windows allocates blocks 
differently that all other operating systems (dsmfmt works differently as well 
on windows than on unix). pre-formatting may be less useful on windows than on 
unix.

I've seen more than a 5 fold increase in performance by properly (and 
patiently) formatting the volumes before allocating them in TSM, on AIX that is.

So much that I even wonder why the TSM formats all volumes in parallel when you 
define multiple volumes in one command, on windows it doesn't hurt to do it 
sequentially, on Unix it really hurts to do it in parallel as TSM does....

> 
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of Paul Zarnowski
> Sent: Wednesday, October 20, 2010 1:07 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Lousy performance on new 6.2.1.1 server with 
> SAN/FILEDEVCLASS storage
> 
> How you connect to the disk storage (i.e., SCSI or SAN) doesn't matter.  This 
> goes more to the issue of how blocks within the volumes are laid out on the 
> spindles.  formatting them one at a time will cause the blocks to be laid out 
> in a more sequential fashion, so that when TSM references the blocks, they 
> will be referenced in a more sequential fashion (assuming you are doing 
> mostly sequential I/O).
> 
> ..Paul
> 

-- 
Met vriendelijke groeten/Kind Regards,

Remco Post
r.post AT plcs DOT nl
+31 6 248 21 622