Re: Predicting when we'll need an extra tape.

[rob@xxxxxxxxx]

It might help, if the Mbytes reported was the size, of the mbytes actually 
written to tape.  Meaning, that if I pass X bytes to it with compression 
turned on, it reports that it compressed it down to Y bytes and reported 
that.  At least that way it would be somewhat standard.  And I wouldn't 
have one tape holding half again as much as another.

Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





Vernon Hamberg <vhamberg@xxxxxxxxxxx> 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
05/16/2005 11:24 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc

Subject
Re: Predicting when we'll need an extra tape.






If you are compressing, there's no way to predict exactly what the 
resulting size will be without running through the compression first - 
Catch-22!  But if you have enough history, you might be able to use some 
heuristic process to learn from the past. It'd still be a guess along the 
lines of predicting the stock market, I think.

At 11:15 AM 5/16/2005, you wrote:

>We like to use the results of the PRTERRLOG TYPE(*VOLSTAT) to predict 
when
>we'll need another tape cartridge in our drive to perform the backup.
>However, it seems that some items can apparently write much more data to
>the cartridge.  I suspect that it depends on the compressibility of the
>data.  I combined all the output from our various boxes to one report:
>
>Volume          ---Temporary Errors---   --------M Bytes--------
>ID                    Read       Write         Read      Written
>SFRI11                   0           0            1       336537
>GFRI11                   0           0            1        22664
>WFRI11                   0           0            1        18984
>DFRI11                   0           0            1       283125
>DFRI21                   0           0            1       155981
>HFRI11                   0           0            1       220831
>6FRI1                    0           0            1       223611
>6FRI2                    0           0            1       223913
>6FRI3                    0           0            1       223380
>6FRI4                    0           0            1       210898
>01WK2                    0           0            1       117170
>02WK2                    0           0            1       110359
>03WK2                    0           0            1       105878
>04WK2                    0           0            1       112585
>05WK2                    0           0            1       114559
>06WK2                    0           0            1        65112
>
>All backups except for the ??WK2 set were done to 3582 LTO2 tape drives.
>The ??WK2 was done to a 3581 LTO1 tape drive.
>
>The S* backup was from a combination of libraries and IFS objects on our
>development partition on the 520.
>The G* backup was from a combination of libraries and IFS objects on a
>little test 270 that's hardly ever used.
>The W* backup was from a combination of libraries and IFS objects on a
>partition on our 570 that is mostly Domino.
>The D* backup was from Domino IFS objects on our busy partition on our
>570.
>The H* backup was all of our BPCS, payroll, and some IFS objects other
>than Domino on our busy partition on our 570.
>The 6FRI* backup was a SAVOBJ of some huge highly compressed objects in a
>library created by the old ADSM (being phased out by TSM on this machine)
>
>Problem statement:
>How can I tell when the S* backup will need another tape cartridge?
>
>
>6FRI* backup SAVOBJ does the following:
>Library     Object                            SIZE   Object    Object
>                                                      Type      Attribute
>PCBACKUP    PCBACKUP00             262,209,286,144   *FILE     PF
>PCBACKUP    PCBACKUP01             262,209,286,144   *FILE     PF
>PCBACKUP    PCBACKUP06             104,884,985,856   *FILE     PF
>PCBACKUP    PCBACKUP07              52,445,650,944   *FILE     PF
>PCBACKUP    PCBACKUP11              52,445,650,944   *FILE     PF
>PCBACKUP    PCBACKUP12              52,445,650,944   *FILE     PF
>PCBACKUP    PCBACKUP02              52,443,553,792   *FILE     PF
>PCBACKUP    PCBACKUP03              52,443,553,792   *FILE     PF
>...
>
>
>
>Rob Berendt
>--
>Group Dekko Services, LLC
>Dept 01.073
>PO Box 2000
>Dock 108
>6928N 400E
>Kendallville, IN 46755
>http://www.dekko.com
>
>--
>This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
list
>To post a message email: MIDRANGE-L@xxxxxxxxxxxx
>To subscribe, unsubscribe, or change list options,
>visit: http://lists.midrange.com/mailman/listinfo/midrange-l
>or email: MIDRANGE-L-request@xxxxxxxxxxxx
>Before posting, please take a moment to review the archives
>at http://archive.midrange.com/midrange-l.

-- 
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.