Switching to RLV:

Some CPU time that would be used for OS overhead for filesystem is freed. This 
could be used for running one more TSM instance?

Memory that would be used for filesystem cache is freed. This could be used by 
TSM for buffers?

I don't know what effect either would have on overall throughput or efficiency, 
but it would be fascinating to find out.

The relative ease of setup of RLV depends on the filesystem it is compared 
with? On extent based filesystems( like NTFS), dsmfmt finishes very quickly?

[RC]

On Wednesday, August 01, 2007, at 04:32AM, "Richard Sims" <rbs AT BU DOT EDU> 
wrote:
>On Jul 31, 2007, at 11:59 PM, Stuart Lamble wrote:
>
>> I am not going to enter into a debate about the relative merits of
>> raw volumes versus files on filesystems, as I have insufficient
>> direct knowledge to judge either way (I'm trusting a more senior
>> colleague to make the right call there. :)
>
>I'll jump in anyway...
>The pure simplicity of RLVs makes them a joy to implement, compared
>to the time-consuming work entailed in implementing a TSM volume
>within a file system.  Their simplicity almost makes them mandatory
>where rapid disaster recovery is vital, as there's far less TSM
>server set-up time getting in the way of recovering your
>organization's functionality.  However, RLV access amounts to
>unbuffered I/O, and that exacts a performance penalty relative to
>file system volumes, where read-ahead provides a nice boost when the
>task at hand involves stepping through the volume.  I use RLVs, and
>it's apparent that Migration is relatively sluggish, as in a disk
>storage pool struggling to stay empty enough to handle all the
>incoming client backup data so as to prevent some backups having to
>go directly to tape.  The TSM Performance Tuning Guide cautions about
>this.
>
>   Richard Sims, Sr. Systems Programmer at Boston University
>
>