Seems like a reasonable compromise would be to just write a script that
marks full copy vols as offsite, and leave them that way. Once they go to
pending or empty, they'd be changed back to onsite. I can live with the
occasional filling volume being reclaimed from copy vols instead of primary
vo
>> On Wed, 19 Nov 2008 11:37:19 -0500, Thomas Denier <[EMAIL PROTECTED]> said:
> The reclamation you describe still creates a volume with 100% of
> its capacity available for future writes,
Future, exactly. Certainly not "right now". I have reusedelay at
somewhere about 5.
> at the cost of wri
-Allen S. Rout wrote: -
>I've whined about this from time to time... I've had tapes 10% full
>get 60% reclaimable and then they get copied. I see no reason to
>reclaim a filling tape unless you figure you can get back at least
>
>(reclaimpercent * max(estcapacity,actualcap))
>
>bytes
>> On Mon, 17 Nov 2008 16:22:30 -0500, Thomas Denier <[EMAIL PROTECTED]> said:
> Yes. We occasionally see onsite filling volumes reclaimed. The mix
> of tape contents that causes this is typically something like the
> following: 51% of the tape occupied by files that have gone inactive
> and then
>> On Mon, 17 Nov 2008 15:35:49 -0500, Paul Zarnowski <[EMAIL PROTECTED]> said:
> At 02:38 PM 11/17/2008, Wanda Prather wrote:
>> No reason I know of you can't have an auto script that does update vol *
>> wherestgpool=copypool access=offsite every day before you start your
>> reclaims.
> Seems
>> On Mon, 17 Nov 2008 13:00:09 -0500, Paul Zarnowski <[EMAIL PROTECTED]> said:
> At 12:50 PM 11/17/2008, Allen S. Rout wrote:
>> >> On Mon, 17 Nov 2008 11:09:55 -0500, Paul Zarnowski <[EMAIL PROTECTED]>
>> But I'm going to claim you don't want to do this, and the bandwidth
>> utilization is in f
zed, with nothing expired
from it yet, will reclaim if the reclamation threshold for the storagepool
is set at 60%.
Nick Cassimatis
- Forwarded by Nicholas Cassimatis/Raleigh/IBM on 11/17/2008 05:14 PM
-
"ADSM: Dist Stor Manager" wrote on 11/17/2008
03:40:19 PM:
>
> Re
-Paul Zarnowski wrote: -
>Seems like if I did this, all the output would have to go to newly
>allocated scratch tapes. No tapes in filling status would be used.
>I could only update the full volumes, I suppose, but are there cases
>where filling tapes can be reclaimed?
Yes. We occasional
@VM.MARIST.EDU
Subject: Re: [ADSM-L] Remote tape drives
At 02:38 PM 11/17/2008, Wanda Prather wrote:
>No reason I know of you can't have an auto script that does update vol *
>wherestgpool=copypool access=offsite every day before you start your
>reclaims.
Seems like if I did this, all th
At 02:38 PM 11/17/2008, Wanda Prather wrote:
No reason I know of you can't have an auto script that does update vol *
wherestgpool=copypool access=offsite every day before you start your
reclaims.
Seems like if I did this, all the output would have to go to newly
allocated scratch tapes. No ta
>> >
>>> > + I have some servers storing remote volumes of 50G MAXCAP, some of
>>> > 20. I haven't noted a big difference between them. Biggest
>>> > theoretical basis for choosing I can come up with is the speed of
>>> > round-robin
> + My biggest pain in the patoot so far comes from individual files
>> > that are much bigger than the remote volume size. I hate re-sending
>> > an initial chunk, then 4 intermediate volumes I know to be identical
>> > to the remote volumes already present, and then re-s
At 12:50 PM 11/17/2008, Allen S. Rout wrote:
>> On Mon, 17 Nov 2008 11:09:55 -0500, Paul Zarnowski <[EMAIL PROTECTED]>
said:
> We are just in the process of creating copy volumes which we intend
> to relocate to an off-site library in a few months.
I want to make certain I'm responding to this
>> On Mon, 17 Nov 2008 11:09:55 -0500, Paul Zarnowski <[EMAIL PROTECTED]> said:
> We are just in the process of creating copy volumes which we intend
> to relocate to an off-site library in a few months.
I want to make certain I'm responding to this correctly; I've been
talking about remote virt
the local site. This means that you can deadlock your way into a
> mess of 'no tapes available' if you get congested.
>
> I find this to be a metastable situation: Things go very smoothly
> until you hit some boundary condition, and then you have a
> turbulence incide
adlock your way into a
> mess of 'no tapes available' if you get congested.
>
> I find this to be a metastable situation: Things go very smoothly
> until you hit some boundary condition, and then you have a
> turbulence incident which takes intense, sustained effort to
&g
ident which takes intense, sustained effort to
resolve.
> How do you know how big the "reallly big pipe" needs to be to take
> care of the reclaims?
This I -do- have a theoretical answer for. See above when I talked
about round-robin on the remote tape drives? You want a pipe b
FCIP. I
> gather that there are TSM sites with remote tape drives. Does their
> experience offer strong reasons to favor or avoid particular
> options?
Just use the network; remote virtual volumes can be as efficient, with
less complexity. I have gotten up to 60MB/s 350 miles away.
Make
cated fibre, FCP over
shared fibre with wave division multiplexing, iFCP, and FCIP. I
gather that there are TSM sites with remote tape drives. Does
their experience offer strong reasons to favor or avoid
particular options?
-
The information contained
ptions for extending FCP tape drive connections
over distances in this range: FCP over dedicated fibre, FCP over
shared fibre with wave division multiplexing, iFCP, and FCIP. I
gather that there are TSM sites with remote tape drives. Does
their experience offer strong reasons to favor or avoid
particul
range: FCP over dedicated fibre, FCP over
shared fibre with wave division multiplexing, iFCP, and FCIP. I
gather that there are TSM sites with remote tape drives. Does
their experience offer strong reasons to favor or avoid
particular options?
21 matches
Mail list logo
