It very much depends on the disk you are putting these on. It is a lot
easier to get bigger cheaper disks to stream data using FILE than to do
lots of small IOPS using DISK.

We were mainly concerned about getting a large amount data to the disk
storage pool and to tape as quickly as possible.

We tested the throughput of our disk using fio and found that it was
able to stream data much much faster than it could do random IO. That is
why we chose FILE. Remember that FILE storage pools use 256KB chunks and
IIRC DISK storage pools are 64KB chunks

Douring the tests we also determined the maximum number of threads that
each volume could support and based the Migration/backup stgp threads
around that. NOTE TSM can use all the threads on the same volume worst
case, unless you stripe accross them.

We were not concerned with Maximum number of mount points because or
backup/archive sessions would never max out disk IO.

Pre-Defining the volumes has a bug if you are using collocation at the
moment.
http://www-01.ibm.com/support/docview.wss?uid=swg1IC95089

HTH

Grant
On 20/09/13 04:40, Paul Zarnowski wrote:

Just to add a few more thoughts to the discussion...

If you ever have to restore your TSM database, you will need to audit all of 
your DISK volumes.  If you set reusedelay appropriately, you can avoid having 
to audit FILE volumes.  Yes, this requires a bit more space, because you'll 
have volumes in PENDING status for a time.

One reason to limit mountlimit would be to try to avoid head thrashing.  
Generally, backup data sent to FILE pools should get good performance because 
you have a stream of data coming into a sequential volume.  DISK pools are 
random, so more head movement.  If you have a high mountlimit, then you could 
offset the benefits of writing sequentially to disk.

We find that running Backup Stgpool from FILE is faster than from DISK.  Our 
Copy stgpools are on remote tape.

..Paul

At 01:20 PM 9/19/2013, Prather, Wanda wrote:

For file devclass, I generally don't worry about maximum volumes because I 
don't set the volumes up as scratch, I predefine them.
Just something else that can cause issues for the customer, and reports of 
other people seeing the coming and going of scratch file volumes causing 
fragmentation in the filesystem.  Better to define the volumes same as a random 
DISK pool.

For mountlimit, it's just the maximum number of client processes you expect to 
be writing to that drive at once. Or set to 999, no reason to restrict it.

For maxcapacity, it just has to be larger than the largest container volume you 
plan to create in that pool.

If you have no plans for dedup, you have no REQUIREment for the file devclass.

And what I HATE about the file devclass, is that you don't get pool failover.  
If the pool fills up before you can migrate out, your backups fail, rather than 
waiting for a tape from the NEXTSTGPOOL.

If the data is going to migrate off to another pool, so the disk pool gets 
emptied frequently  anyway, what benefit to having a filepool?
And if it isn't emptied every day, you will have to run reclamation on it.

So when it's just a "buffer" diskpool, I prefer to use DISK rather than FILE.






-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Zoltan Forray
Sent: Thursday, September 19, 2013 11:34 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] DISK vs FILE DevClass

We are in a transition of our SAN storage from one EMC box to another.
Since this requires my relocating 18TB of TSM server storage, I thought I would 
take this opportunity to revisit FILE devclass vs DISK, which we are using now.

I have been reading through the Linux Server Admin Guide on the "pro's and 
con's" of both devclasses.  Still not sure if it would be better to go with
FILE.   Here is some info on what this server does,.

For the server that would be using this storage, the sole backups are Lotus 
Notes/Domino servers, so the backup data profile is not your usual data mix 
(largely Notes TDP).

No dedupe and no plans to dedupe.
No active storage and no need for it.
4-5TB daily with spikes to 15TB on weekends - 95%+ is TDP

When creating/updating the FILE devclass, how do I calculate/guesstimate the 
values for MOUNTLIMIT and MAXIMUM CAPACITY as well as the MAXIMUM VOLUMES?

Unfortunately, the storage they assigned to me on the VNX5700 is broken up into 
8-pieces/luns, varying from 2.2TB to 2.4TB, each.

Looking for some feedback on which way we should go and why one is preferable 
than the other.

--
*Zoltan Forray*
TSM Software & Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zforray AT vcu DOT edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will never 
use email to request that you reply with your password, social security number 
or confidential personal information. For more details visit 
http://infosecurity.vcu.edu/phishing.html

--
Paul Zarnowski                            Ph: 607-255-4757
Manager of Storage Services               Fx: 607-255-8521
IT at Cornell / Infrastructure            Em: psz1 AT cornell DOT edu
719 Rhodes Hall, Ithaca, NY 14853-3801