Re: tape selection policy
On Mon, Aug 30, 2010 at 2:55 PM, Gene Heskett wrote: > Dustin; I changed to that syntax and amcheck objected to having both the > tapedev and that sort of syntax in the tpchanger line unless I was using > the old chg-disk, so I commented the tapedev line, and gave tpchanger the > full path to my vtapes ":/amandatapes/Dailys", and amcheck was again happy. > If that is not in the man pages yet (I didn't check yet) then it probably > should be. Stateing that as a path spec to where they are would be helpful > to the newbie. > > Yeah, I'm still using the 3.2alpha snapshots, playing canary. svn.3343 > ATM, worked fine last night with the old syntax. Right - the "old syntax" still works, but let's try not to talk about it in front of n00bs :) In modifying the manpages, I tried to err on the side of the new syntax, while still documenting the old syntax. So amanda-changers(7) says: The preferred method of specifying configuration for a changer is as a "changer" section in amanda.conf(5). The tapedev parameter then indicates, by name, the changer that will be used by default by most Amanda programs. For example: I'll be happy to merge any suggested additions/modifications to the manpage. Dustin -- Open Source Storage Engineer http://www.zmanda.com
Re: tape selection policy
On Monday, August 30, 2010 05:06:22 pm Dustin J. Mitchell did opine: > On Mon, Aug 30, 2010 at 2:55 PM, Gene Heskett wrote: > > Dustin; I changed to that syntax and amcheck objected to having both > > the tapedev and that sort of syntax in the tpchanger line unless I > > was using the old chg-disk, so I commented the tapedev line, and gave > > tpchanger the full path to my vtapes ":/amandatapes/Dailys", and > > amcheck was again happy. If that is not in the man pages yet (I > > didn't check yet) then it probably should be. Stateing that as a > > path spec to where they are would be helpful to the newbie. > > > > Yeah, I'm still using the 3.2alpha snapshots, playing canary. > > svn.3343 ATM, worked fine last night with the old syntax. > > Right - the "old syntax" still works, but let's try not to talk about > it in front of n00bs :) Chuckle... > > In modifying the manpages, I tried to err on the side of the new > syntax, while still documenting the old syntax. So amanda-changers(7) > says: > > The preferred method of specifying configuration for a changer is as a > "changer" section in amanda.conf(5). The tapedev parameter then > indicates, by name, the changer that will be used by default by most > Amanda programs. For example: > > I'll be happy to merge any suggested additions/modifications to the > manpage. > > Dustin Yes, I have since read that, and I'll see what sort of gotcha's I run into in trying to set that up, but not today, I'm half cooked. Thanks Dustin. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Why are these athletic shoe salesmen following me??
Re: tape selection policy
On Monday, August 30, 2010 03:47:05 pm Dustin J. Mitchell did opine: > On Sun, Aug 29, 2010 at 9:28 PM, Jon LaBadie wrote: > > I've never worked with a barcoded changer so I never had a > > "fast-searchable" experience. You do not explicitly say so, but I > > assume chg-disk is now fast-searchable? That's not historical :) > > To be clear, the old chg-disk is still not fast-searchable. The new one > is. > > Old: > tpchanger "chg-disk" > > New: > tpchanger "chg-disk:/amanda/vtapes" > > Dustin Dustin; I changed to that syntax and amcheck objected to having both the tapedev and that sort of syntax in the tpchanger line unless I was using the old chg-disk, so I commented the tapedev line, and gave tpchanger the full path to my vtapes ":/amandatapes/Dailys", and amcheck was again happy. If that is not in the man pages yet (I didn't check yet) then it probably should be. Stateing that as a path spec to where they are would be helpful to the newbie. Yeah, I'm still using the 3.2alpha snapshots, playing canary. svn.3343 ATM, worked fine last night with the old syntax. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) The two most common things in the Universe are hydrogen and stupidity. -- Harlan Ellison
Re: tape selection policy
On Sun, Aug 29, 2010 at 9:28 PM, Jon LaBadie wrote: > I've never worked with a barcoded changer so I never had a "fast-searchable" > experience. You do not explicitly say so, but I assume chg-disk is > now fast-searchable? That's not historical :) To be clear, the old chg-disk is still not fast-searchable. The new one is. Old: tpchanger "chg-disk" New: tpchanger "chg-disk:/amanda/vtapes" Dustin -- Open Source Storage Engineer http://www.zmanda.com
Re: tape selection policy
Dustin J. Mitchell wrote: On Fri, Aug 27, 2010 at 2:41 PM, Chris Hoogendyk wrote: There was an exchange on the list in the last few months where I asked that question and Dustin replied. He said that the historical algorithm had a strong preference for an already written tape if one was available that could be written to. I think he said that now that the new taper was out he was thinking about implementing a more sane algorithm. Wow, I'm cited twice as historical precedent! If you look closely at amanda-taperscan(7), you'll see that the unknown component of the algorithm that has changed in more recent versions is whether the changer is fast-searchable. In the past, only chg-zd-mtx+barcodes was searchable. Even chg-disk acted like a barcode-less changer, and just scanned slots in order to find a tape. That's an interesting nuance. chg-zd-mtx+barcodes is exactly what I have on all my installations. That explains why others might have had different experiences. The traditional algorithm will "stumble across" new tapes with a non-fast-searchable changer, but with a fast-searchable changer, it will always search for the oldest reusable tape, paying no attention to new tapes. It's unfortunate, but it's the way things have worked historically. -- --- Chris Hoogendyk - O__ Systems Administrator c/ /'_ --- Biology & Geology Departments (*) \(*) -- 140 Morrill Science Center ~~ - University of Massachusetts, Amherst --- Erdös 4
Re: tape selection policy
On Sun, Aug 29, 2010 at 11:10:40AM -0400, Dustin J. Mitchell wrote: > On Fri, Aug 27, 2010 at 2:41 PM, Chris Hoogendyk > wrote: > > There was an exchange on the list in the last few months where I asked that > > question and Dustin replied. He said that the historical algorithm had a > > strong preference for an already written tape if one was available that > > could be written to. I think he said that now that the new taper was out he > > was thinking about implementing a more sane algorithm. > > Wow, I'm cited twice as historical precedent! > > If you look closely at amanda-taperscan(7), you'll see that the > unknown component of the algorithm that has changed in more recent > versions is whether the changer is fast-searchable. In the past, only > chg-zd-mtx+barcodes was searchable. Even chg-disk acted like a > barcode-less changer, and just scanned slots in order to find a tape. > > The traditional algorithm will "stumble across" new tapes with a > non-fast-searchable changer, but with a fast-searchable changer, it > will always search for the oldest reusable tape, paying no attention > to new tapes. > > It's unfortunate, but it's the way things have worked historically. I've never worked with a barcoded changer so I never had a "fast-searchable" experience. You do not explicitly say so, but I assume chg-disk is now fast-searchable? That's not historical :) For my setup to reach all tapes used will take some time. Maybe you know the answer to this question. I've just experienced the skipping of new tapes to reuse just the tapecycle number of tapes. But how will the taperscan act if all the tapes have been used but tapecycle is less than the number of available tapes. As an example with numbers: suppose I have a 20 tape changer and fill it with labeled tapes. Then, with a tapecycle of 20 all tapes get used in order. Suppose I then reduce tapecycle to 15. Will the new tapescan algorithm skip 5 of the tapes and only use 15? -- Jon H. LaBadie [email protected] JG Computing 12027 Creekbend Drive (703) 787-0884 Reston, VA 20194 (703) 787-0922 (fax)
Re: tape selection policy
On Fri, Aug 27, 2010 at 2:41 PM, Chris Hoogendyk wrote: > There was an exchange on the list in the last few months where I asked that > question and Dustin replied. He said that the historical algorithm had a > strong preference for an already written tape if one was available that > could be written to. I think he said that now that the new taper was out he > was thinking about implementing a more sane algorithm. Wow, I'm cited twice as historical precedent! If you look closely at amanda-taperscan(7), you'll see that the unknown component of the algorithm that has changed in more recent versions is whether the changer is fast-searchable. In the past, only chg-zd-mtx+barcodes was searchable. Even chg-disk acted like a barcode-less changer, and just scanned slots in order to find a tape. The traditional algorithm will "stumble across" new tapes with a non-fast-searchable changer, but with a fast-searchable changer, it will always search for the oldest reusable tape, paying no attention to new tapes. It's unfortunate, but it's the way things have worked historically. Dustin -- Open Source Storage Engineer http://www.zmanda.com
Re: tape selection policy
Jon LaBadie wrote: Perhaps my memory is slipping, but I recall amanda would use a new tape if it encountered one. I.e. it wouldn't search for the specific tape in the past rotation if it encountered a new tape first. The current release of amanda seems to ignore all new tapes even if there are a hundred new, labelled tapes. I've typically configured amanda with tapecycle a few less than the number actually labelled and in rotation. An benefit this obtains is when a tape goes bad, or otherwise is missing, amanda does not have to go into degraded mode because no usable tape is found. Was this an intentional change in taper policy? No change. Been that way. There was an exchange on the list in the last few months where I asked that question and Dustin replied. He said that the historical algorithm had a strong preference for an already written tape if one was available that could be written to. I think he said that now that the new taper was out he was thinking about implementing a more sane algorithm. What I did to get around it was to temporarily set my tapecycle to the total number of tapes, including new ones, currently available. When it had run through the new tapes, I then put the tapecycle back down a bit. Everything worked out fine. I think the reason I had not run into the problem before was because my library only held a part of the tapecycle number of tapes. So the ones that would have been re-writeable were not in the library at the time when the new tapes were being encountered and used. I ran into the problem when I had a new installation and was filling out the space available in the library. -- --- Chris Hoogendyk - O__ Systems Administrator c/ /'_ --- Biology & Geology Departments (*) \(*) -- 140 Morrill Science Center ~~ - University of Massachusetts, Amherst --- Erdös 4
Re: tape selection policy
On Fri, Aug 27, 2010 at 02:23:32PM -0400, Jean-Francois Malouin wrote:
> Jon,
>
> * Jon LaBadie [20100827 14:05]:
> > Perhaps my memory is slipping, but I recall amanda
> > would use a new tape if it encountered one. I.e.
> > it wouldn't search for the specific tape in the
> > past rotation if it encountered a new tape first.
> >
> > The current release of amanda seems to ignore all
> > new tapes even if there are a hundred new, labelled
> > tapes.
>
> I started a thread on this called 'No acceptable volumes found'
> in August. You might want to read it.
>
> I had the same problem you mention: after adding 30 new tapes
> to the tapecycle amanda was still refusing to use them and prefered
> the old already written tapes...
I remember there was such a thread. I look at it.
> >
> > I've typically configured amanda with tapecycle a
> > few less than the number actually labelled and in
> > rotation. An benefit this obtains is when a tape
> > goes bad, or otherwise is missing, amanda does
> > not have to go into degraded mode because no
> > usable tape is found.
> >
> > Was this an intentional change in taper policy?
>
> From what I understand from Dustin in the above mentionned thread is
> that the taper scanner algorithm ('traditional') is doing what it says
> and that I (and you) were living out of an undocumented feature from
> the previous versions...
>
It was "documented" in the sense of the behavior being mentioned many
times in this list.
Have you had any experience with setting tapecycle to match the
actual number of tapes and reducing it after a complete cycle?
Thanks for the info.
--
Jon H. LaBadie [email protected]
JG Computing
12027 Creekbend Drive (703) 787-0884
Reston, VA 20194 (703) 787-0922 (fax)
Re: tape selection policy
Jon,
* Jon LaBadie [20100827 14:05]:
> Perhaps my memory is slipping, but I recall amanda
> would use a new tape if it encountered one. I.e.
> it wouldn't search for the specific tape in the
> past rotation if it encountered a new tape first.
>
> The current release of amanda seems to ignore all
> new tapes even if there are a hundred new, labelled
> tapes.
I started a thread on this called 'No acceptable volumes found'
in August. You might want to read it.
I had the same problem you mention: after adding 30 new tapes
to the tapecycle amanda was still refusing to use them and prefered
the old already written tapes...
>
> I've typically configured amanda with tapecycle a
> few less than the number actually labelled and in
> rotation. An benefit this obtains is when a tape
> goes bad, or otherwise is missing, amanda does
> not have to go into degraded mode because no
> usable tape is found.
>
> Was this an intentional change in taper policy?
>From what I understand from Dustin in the above mentionned thread is
that the taper scanner algorithm ('traditional') is doing what it says
and that I (and you) were living out of an undocumented feature from
the previous versions...
regards,
jf
>
> --
> Jon H. LaBadie [email protected]
> JG Computing
> 12027 Creekbend Drive(703) 787-0884
> Reston, VA 20194(703) 787-0922 (fax)
--
<° >< Jean-François Malouin McConnell Brain Imaging Centre
Systems/Network Administrator Montréal Neurological Institute
3801 Rue University, Suite WB219 Montréal, Québec, H3A 2B4
Phone: 514-398-8924 Fax: 514-398-8948
