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
>> 
>> 
>