ADSM-L

Re: Tape drive recomendations

2002-10-31 19:21:34
Subject: Re: Tape drive recomendations
From: Steve Schaub <Steve.Schaub AT HAWORTH DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 31 Oct 2002 12:14:58 -0500
If I'm reading this correctly, only migrating my diskpool down to 10% is
hurting my DRM reclamation?
Are you saying that putting in a 10TB diskpool that never goes to
primary tape (only dr copies) would give me monstrously bad
reclamations?  Our current main diskpool is 100gb on SSA and has caching
on.  I haven't had a terrible problem with DR reclamation, though the
storage pool backup to DRM only has a throughput of about 5mb/sec.

-----Original Message-----
From: TRushfor AT CITY.WINNIPEG.MB DOT CA 
Sent: Thursday, October 31, 2002 11:03 AM
To: CITY.WINNIPEG.MB.CA.TRushfor; VM.MARIST.EDU;.ADSM-L
Subject: Re: Tape drive recomendations


And the issue is still there if you don't use CACHE=YES but don't
completely clear your backup pool.

We have more disk in our storagepool than is required for one night's
incremental - so we thought keeping some backups on disk was a good
thing (why migrate to tape if you don't need the space).


Tim Rushforth
City of Winnipeg

-----Original Message-----
From: Bill Boyer [mailto:bill.boyer AT VERIZON DOT NET]
Sent: October 31, 2002 9:01 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Tape drive recomendations

Be careful of your copypool reclamations with the disk cache turned on!!
There is a BIG performance hit on reclamation when the primary copy of
the file is on a DISK direct access storage pool. Then the
MOVESIZETHRESH and MOVEBATCHSIZE values are thrown out the window and
the files are processed one at a time.

What I've done to relieve the restore times is to not MIGRATE the disk
pools until the end of the day. That way restoring from last night is
quick. I had a client where they wanted CACHE=YES on a 60GB disk pool.
The offsite copypool reclamation ran for 2-days! Changed it so that
migration started at 5:00pm and nobody complained about restore times.

Bill Boyer
DSS, Inc.

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
Steve Schaub
Sent: Thursday, October 31, 2002 5:59 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Tape drive recomendations


This is one reason I am looking into some of the new, cheaper ATA-based
disk arrays.  98% of restores come from the last few versions, so if you
can size the diskpool large enough (and turn caching on) that you rarely
need to go to tape, restores scream.  Some of the initial prices I am
seeing are < $10k per TB.  It's not SSA, but for a diskpool it might be
fast enough.

-----Original Message-----
From: asr AT UFL DOT EDU
Sent: Wednesday, October 30, 2002 10:15 PM
To: UFL.EDU.asr; VM.MARIST.EDU;.ADSM-L
Subject: Re: Tape drive recomendations
2

=> On Wed, 30 Oct 2002 16:42:14 -0600, "Coats, Jack"
<Jack.Coats AT BANKSTERLING DOT COM> said:

> From my fox hole, LTO works great, but in some ways it is 'to big'. 
> The spin time on the tapes is measured as about 3 minutes to rewind 
> and unmount a tape.  Meaning if you have to scan down a tape to 
> restore a file it can be a while.  Very fast tapes tend to be small, 
> so it is a real tradeoff.

> Speed of restore is starting to be a factor here and I have seen 
> several posts where that is becoming more of an issue at many sites. 
> But the architecture of TSM that makes it great, also gets in the way 
> of high speed restores, unless you have lots of slots in a large 
> library for a relatively small number of clients (co-location and/or 
> backup sets - for theses many smaller tapes might be better, but I 
> digress).


Our call on this is congealing: Use the LTO for less-often-read storage.
i.e.: copy pools.  If we can have primary pools on 3590s, we can get up
to 60G raw on the -K volumes.  That seems plenty at the moment.

We can use the 200G-raw (coming soon!) LTO volumes for copies, and read
from them correspondingly less often.

LTO drives are, at the very least, a cheap way to increase your drive
count.

- Allen S. Rout

<Prev in Thread] Current Thread [Next in Thread>