This is hackery at it's worst, or best, depending on your point of view.  This 
is how we got around the 8.7TB limit:

Backups were going to instance macc-4-1.
Set up a new instance, macc-4-3, as a virtual volume instance.  Set up a new 
devclass/stgpool on macc-4-1 to send virtual volumes to macc-4-3, max size 
100G.  Rob disk pool volumes from macc-4-1 and put them on macc-4-3.  Set 
backups to go to the new virtual volume pool.
Backups are still going to disk, just in a round-about way.  Once they're to 
disk macc-4-3, they'll be migrated back to tape on macc-4-1 at our leisure, and 
hopefully not get preempted.

I originally tried setting up all the virtual volume stuff within macc-4-1, but 
the TSM instance didn't like mounting virtual volumes off of itself.

Hopefully this solution is temporary.

--
Cameron Hanover
chanover AT umich DOT edu

"Let's get dangerous."
--Darkwing Duck

On Jun 5, 2010, at 5:09 PM, Cameron Hanover wrote:

> For what it's worth, after some go-rounds with IBM development, it appears 
> there's an 8.7TB limit being hit somewhere.  That's why the backup is going 
> to tape rather than disk.  They are currently investigating the ramifications 
> of removing this limit.
> I'm working on a hair-brained workaround.  If it works, I'll post it to list.
> 
> -
> Cameron Hanover
> chanover AT umich DOT edu
> 
> "Chaos was the law of nature.  Order was the dream of man."
> --Henry Brooks Adams
> 
> 
> 
> On May 17, 2010, at 8:45 AM, c.hanover wrote:
> 
>> My understanding of an NDMP differential backup is that TSM assumes the 
>> backup will be the full size of the filesystem at the beginning of the 
>> backup, and places it accordingly.  If that's the case, then that isn't 
>> true, because the backup of the other large filesystem on that NAS goes to 
>> disk, and it's a 5TB filesystem with 4TB of data.
>> 
>> --
>> Cameron Hanover
>> chanover AT umich DOT edu
>> 
>> "A computer once beat me at chess, but it was no match for me at kick 
>> boxing."
>> --Emo Philips
>> 
>> On May 15, 2010, at 5:00 AM, Remco Post wrote:
>> 
>>> On DISK type storage, TSM can't split a transaction over multiple volumes, 
>>> you need FILE type storage to be able to do that. Since NDMP dumps are a 
>>> single transaction.....
>>> 
>>> 
>>> On 14 mei 2010, at 17:29, c.hanover wrote:
>>> 
>>>> Our setup:
>>>> TSM 5.4.1.2 Server on Linux, a 19TB disk pool dedicated to the management 
>>>> class for the NAS node. The disk pool is largely made up of 1.8TB volumes 
>>>> on a RAID5, the maxfilesize is set to 'nolimit', highmig=100, lowmig=99.  
>>>> The NAS is a BlueArc, according to the trace:
>>>> NAS Vendorname:     BlueArc Corp.
>>>> Productname:    Silicon Server NDMP.
>>>> Revisionnumber: 6.1.
>>>> Hosttype:    BOS.
>>>> Versionnumber: 6.1.
>>>> 
>>>> The filesystem in question:
>>>> fsName=/__VOLUME__/cifpilot1, fsType=WFS, fsId=2, fsCap=10Tb, fsOcc=8650Gb
>>>> 
>>>> When I perform a backup of that filesystem (backup node 
>>>> XXXXXXXXXXXXX.umich.edu /__VOLUME__/cifpilot1 toc=yes mode=diff), rather 
>>>> than go to the empty disk pool, it immediately goes to tape.  This is 
>>>> causing a problem because the job is getting preempted when the scheduled 
>>>> migrations occur on the other servers at 7am.  Other smaller filesystems 
>>>> (0.4 and 5TB, respectively) backup to disk just fine.
>>>> I've moved the backup as early as I could to try and get it to complete 
>>>> before migrations, but that's not working anymore.  I need to figure out 
>>>> why this backup is going to tape rather than to disk.
>>>> 
>>>> Anybody have any ideas?
>>>> 
>>>> -
>>>> Cameron Hanover
>>>> chanover AT umich DOT edu
>>>> 
>>>> "Necessity is the plea for every infringement of human freedom.  It is the 
>>>> argument of tyrants; it is the creed of slaves."
>>>> --William Pitt, House of Commons, 11/18/1783
>>> 
>>> -- 
>>> 
>>> Met vriendelijke groeten/Kind regards,
>>> 
>>> Remco Post
>>> 
>>> 
>> 
>