|
Re: [ADSM-L] DEVCLASS=FILE - what am I missing
2015-02-13 13:30:26
Sure there were plenty of errors:
2/12/2015 10:00:23 PM ANR0522W Transaction failed for session 2639 for node
RO-CVS (Linux x86-64) - no space available in storage pool BACKUPPOOL and
all successor pools.
2/12/2015 10:04:20 PM ANR0522W Transaction failed for session 2648 for node
RDO3 (WinNT) - no space available in storage pool BACKUPPOOL and all
successor pools.
2/12/2015 10:05:00 PM ANR0522W Transaction failed for session 2636 for node
BARRACUDA.RADONC.RDO.MCVH-VCU.EDU (Linux86) - no space available in storage
pool BACKUPPOOL and all successor pools.
2/12/2015 10:08:44 PM ANR0522W Transaction failed for session 2653 for node
RO-MCCB129B (WinNT) - no space available in storage pool BACKUPPOOL and all
successor pools.
2/13/2015 1:13:01 AM ANR0522W Transaction failed for session 2740 for node
TSMCIFS2 (WinNT) - no space available in storage pool BACKUPPOOL and all
successor pools.
There was plenty of space in the disk. It just hit the max number of
volumes......
But why didn't it reclaim the volumes it should have, that were less than
50% used? Am I supposed to do something to start reclamation processing
for FILE pools? My tapes automatically reclaim themselves........
On Fri, Feb 13, 2015 at 1:16 PM, Steven Langdale <steven.langdale AT gmail DOT
com>
wrote:
> As the number of vols is damn close to Max scratch. I'd say you ran out.
> No thing in actlog? Bung it up and see what happens.
>
> On Fri, 13 Feb 2015 17:15 Zoltan Forray <zforray AT vcu DOT edu> wrote:
>
> > Up until recently, I have always used DEVCLASS=DISK for disk storage and
> > always preformatted/allocated the disk volumes into multiple chunks to
> all
> > for multi-I/O benefits.
> >
> > When I recently stood-up a new server, I decided to try DEVCLASS=FILE for
> > disk-based storage/incoming backups.
> >
> > I thought I understood that FILE type storage was basically
> > "tape/sequential files on disk" and would act accordingly and things like
> > reclamation now applied so when the file chunks (I defined 50GB file
> sizes)
> > got below the reclaim value, it would reclaim such files, create new ones
> > and delete the old ones automagically.
> >
> > Well, last night became a disaster. Backups failing all over because it
> > couldn't allocate any more files and also would not automatically shift
> to
> > use the "nextpool" which is defined as a tape pool.
> >
> > So, what am I doing wrong? What assumptions are wrong? Here is the
> > devclass values with the empty values left out...:
> >
> > Device Class Name: TSMFS
> > Device Access Strategy: Sequential
> > Storage Pool Count: 1
> > Device Type: FILE
> > Format: DRIVE
> > Est/Max Capacity (MB): 51,200.0
> > Mount Limit: 40
> > Directory: /tsmpool
> >
> > Here is the lone stgpool that used this devclass:
> >
> > 12:06:21 PM GALAXY : q stg backuppool f=d
> > Storage Pool Name: BACKUPPOOL
> > Storage Pool Type: Primary
> > Device Class Name: TSMFS
> > Estimated Capacity: 7,106 G
> > Space Trigger Util: 84.5
> > Pct Util: 80.9
> > Pct Migr: 80.9
> > Pct Logical: 99.2
> > High Mig Pct: 85
> > Low Mig Pct: 75
> > Migration Delay: 0
> > Migration Continue: Yes
> > Migration Processes: 1
> > Reclamation Processes: 1
> > Next Storage Pool: PRIMARY-ONSITE
> > Reclaim Storage Pool:
> > Maximum Size Threshold: No Limit
> > Access: Read/Write
> > Description:
> > Overflow Location:
> > Cache Migrated Files?:
> > Collocate?: No
> > Reclamation Threshold: 59
> > Offsite Reclamation Limit:
> > Maximum Scratch Volumes Allowed: 143
> > Number of Scratch Volumes Used: 137
> > Delay Period for Volume Reuse: 0 Day(s)
> > Migration in Progress?: No
> > Amount Migrated (MB): 0.00
> > Elapsed Migration Time (seconds): 1,009
> > Reclamation in Progress?: No
> > Last Update by (administrator): ZFORRAY
> > Last Update Date/Time: 02/13/2015 11:44:23
> > Storage Pool Data Format: Native
> > Copy Storage Pool(s):
> > Active Data Pool(s):
> > Continue Copy on Error?: Yes
> > CRC Data: No
> > Reclamation Type: Threshold
> > Overwrite Data when Deleted:
> > Deduplicate Data?: No
> > Processes For Identifying Duplicates:
> > Duplicate Data Not Stored:
> > Auto-copy Mode: Client
> > Contains Data Deduplicated by Client?: No
> >
> > I calculated the "Max Scratch Volumes" value based on having ~7.6TB
> > filesystem so 50GB * 143 = 7.1TB
> >
> > This morning when I checked, there were plenty of volumes with <40%
> > utilized. SO why didn't reclaim kick-in? or am I totally off on this
> > assumption? I manually performed move data on them and it freed things
> > up.
> > --
> > *Zoltan Forray*
> > TSM Software & Hardware Administrator
> > BigBro / Hobbit / Xymon 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
BigBro / Hobbit / Xymon 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
|
|
|
