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.prat...@icfi.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@VM.MARIST.EDU] On Behalf Of > Zoltan Forray > Sent: Thursday, September 19, 2013 11:34 AM > To: ADSM-L@VM.MARIST.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 > zfor...@vcu.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 zfor...@vcu.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
