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
|
