ADSM-L

Re: [ADSM-L] ADSM-L Win2K3 backu

2008-02-02 08:37:48
Subject: Re: [ADSM-L] ADSM-L Win2K3 backu
From: Richard Sims <rbs AT BU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Sat, 2 Feb 2008 08:33:27 -0500
On Feb 1, 2008, at 5:46 PM, Sam Sheppard wrote:

---------------------------- Top of message
----------------------------
--> 02-01-08  14:42  S.SHEPPARD     (SHS)    Re: ADSM-L Win2K3 backu

Can I infer from you comments that you find the FILE DEVCLASS to be a
better performer?  This is our first server on Unix; our other 2 TSM
servers are running on z/OS and have other known bottlenecks.  I
hadn't
ever considered trying non DISK DEVCLASS for the primary pools.
Perhaps
I should.


FILE devclass has the advantage of being a serially used, sequential
disk resource with no simultaneous contention from sessions/
processes, no block management or locking needed, and effectively no
repositioning prior to next write.  As such, its performance can be
far better than DISK devclass.  In both devclasses, however, one has
to be mindful of the characteristics of the underlying technology.
The FILE devclass operates within a directory within a file system,
where it is common that the file system is also used for other
purposes.  As such, free space blocks within the file system may be
scattered rather than contiguous, resulting in what is know as
Fragmentation and thus performance degradation as repositioning is
required to move to the next clump of space - and reposition after
having served the other users of the disk.  A dedicated file system
reduces fragmentation; and a dedicated disk partition can eliminate
fragmentation.  Repositioning can be eliminated where a disk can be
dedicated to the purpose.  Naturally, disk arrays and RAID complicate
the picture, but in general whatever you can do to provide
contiguous, uncontested space results in the best performance.  And,
of course, this is where tape excels, and why it remains so appealing
for backup streaming, not to mention its offered additional features
of hardware compression and encryption.

  Richard Sims

<Prev in Thread] Current Thread [Next in Thread>