Re: Fundamental Migration Design Flaw

I have to second what Mark said.  We run relatively small disk pools on
purpose, and I have a MaxSize set on every one of them.  I have some
Oracle table files that are 2 GB each.  There is simply no reason to store
that on disk instead of tape, so we send that kind of stuff straight to
tape.  On our GigE connected server writing to LTO-1, we sustain 27 MB/s
as measured by TSM.  Restore performance would be about equal, so the
minute or so to mount the tape and seek the file just isn't significant.

One thing to keep in mind is that the MaxSize applies to *aggregate* size,
not "file" size.  For the 24 GB disk pool upstream of our LTO I set a
MaxSize = 50 MB with a client aggregate size capped at 48 MB.  That data
path gets backups from our main file servers.  So any file larger than 50
MB will go direct to tape.  By morning, the disk pool is usually 30-60%
full, which is perfect.  The smaller, aggregated files stay on disk until
5 pm when we force migrate them to tape.

Works like a charm.

Tab Trepagnier
TSM Administrator
Laitram LLC







"Stapleton, Mark" <stapleto AT BERBEE DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
10/05/2003 10:57 PM
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: Fundamental Migration Design Flaw


There is a decent workaround until more diskpool space arrives. Set the
storage pool parameter MAXSIZE to a setting that will ensure that these
"open files" (which must be large and voluminous, based on the fact that
they would take up almost half of a 42GB diskpool) go directly to tape
rather than disk. Also, you could consider changing copy serialization so
that the TSM server doesn't try to resend those "open files" so many
times.

To tell the truth, if you have 20GB+ of "open files", consider moving your
TSM server to version 5.2, which has better handling of "open files". What
kind of files are they, anyway?

Fundamental flaw? I don't think so. Your situation contains an unfortunate
combination of circumstances that don't normally in most IT environments.

--

Mark Stapleton (stapleton AT berbee DOT com)