I am not sure if this is an issue with file device class, but I define the max
capacity as 2 GB and started backups direct to file device class. Many of my
clients has excessive media wait the next morning report. After that I move
them back to a small disk device class that migrate to a file device class and
all of the media wait went away.
-----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 10:36 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: DISK vs FILE DevClass
Wanda,
As always, thanks for the education lesson.
>>>>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.
Well, that pretty much tells me I don't want to bother with FILE devclass.
Strange that it wouldn't handle this situation the same way with DISK - if
the next pool is sequential/tape, like it normally is. After all, isn't
FILE "sequential access disk"?
While in the past this system used to overflow their disk LZ all-the-time,
as long as the TS3500 is functioning, we manage migration/overflow very
well, so this should not be a problem. But it still sounds like a hassle!
Time to start formatting the 18TB of new SAN storage, which will take many
days since we have to single-thread to avoid fragmentation (for you Linux
folks, yes it is ext4 but until RH 6, it still formats all of the storage
in each volume - once you get to RH 6, the allocation/format takes about
2-seconds).
On Thu, Sep 19, 2013 at 1:20 PM, Prather, Wanda <Wanda.Prather AT icfi DOT
com>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
>
--
*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
|
