ADSM-L

Re: Performance Large Files vs. Small Files

2001-02-21 16:18:32
Subject: Re: Performance Large Files vs. Small Files
From: bbullock <bbullock AT MICRON DOT COM>
Date: Wed, 21 Feb 2001 14:18:52 -0700
        That is also an option that we have not considered. It actually
sounds like a good one. I'll bring it up to management.
        The only problem I see in this is the $$$ needed to purchase a TSM
server license for every manufacturing host we try to back up.
        I don't know about your shops, but with the newest "Point based"
pricing structure that Tivoli implemented back in November (I believe it was
about then). They are now wanting to charge you more $$$ to run the TSM
server on a multi-cpu unix host than on a single host NT box. In our shop
where we run TSM on beefy S80s, that means a price change that is
exponentially larger than what we have paid in the past for the same
functionality.


Ben Bullock
UNIX Systems Manager


> -----Original Message-----
> From: Suad Musovich [mailto:suad AT CCU1.AUCKLAND.AC DOT NZ]
> Sent: Wednesday, February 21, 2001 4:37 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Performance Large Files vs. Small Files
>
>
> On Tue, Feb 20, 2001 at 03:21:34PM -0700, bbullock wrote:
> ...
> >         How many files? Well, I have one Solaris-based host
> that generates
> > 500,000 new files a day in a deeply nested directory
> structure (about 10
> > levels deep with only about 5 files per directory). Before
> I am asked, "no,
> > they are not able to change the directory of file structure
> on the host. It
> > runs proprietary applications that can't be altered". They
> are currently
> > keeping these files on the host for about 30 days and then
> deleting them.
> >
> >         I have no problem moving the files to TSM on a
> nightly basis, we
> > have a nice big network pipe and the files are small. The
> problem is with
> > the TSM database growth, and the number of files per
> filesystem (stored in
> > TSM). Unfortunately, the directories are not shown when you
> do a 'q occ' on
> > a node, so there is actually a "hidden" number of database
> entries that are
> > taking up space in my TSM database that are not readily
> apparent when
> > looking at the output of "q node".
>
> Why not put a TSM server on the Solaris box and back it up to
> one of the other
> servers as a virtual volume.
> It would redistribute the database to the Solaris host and
> the data is kept
> as a large object on the tape-attached TSM server.
>
> I also remember reading about grouping files together as a
> single object. I can't
> remember if it did selective groups of files or just whole
> filesystems.
>
> Cheers, Suad
> --
>