On Saturday 06 November 2004 17:40, Gavin Henry wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Saturday 06 Nov 2004 22:26, Jon LaBadie wrote:
>> On Sat, Nov 06, 2004 at 08:44:39PM +0000, Gavin Henry wrote:
>> > On Saturday 06 Nov 2004 17:35, Jon LaBadie wrote:
>> > > So the correct answer, whether you like it or not, is "a new
>> > > tape" labelled, but unused previously. So, amcheck saying
>> > > "new tape" is correct, because you have not yet written to
>> > > your entire tape cycle. It will expect, and use, a new tape
>> > > with any label in the drive the next time an amdump is run.
>> >
>> > As long as it matches the labelstr.
>>
>> I looked over my answer and thought ... should I add that.
>> But you are correct.
>
>Thanks.
>
>> > > If you had tape2
>> > > in the drive, it would have reported it was a appropriate
>> > > tape.
>> >
>> > Yes.
>>
>> And I probably should have said "I think it would say a new tape
>> was needed, and that tape2 was ok". But I wasn't certain, so I
>> did not..
>
>OK.
>
>> > > Thus it is just saying this is the next tape listed
>> > > in the tapelist file. But it is incorrect because you could
>> > > stick in tape 12 at this time and amcheck and amdump would be
>> > > happy.
>> >
>> > Because it matches labelstr, but should they mind? If you number
>> > them. But saying that, does the regex require a number in it? If
>> > so, it should ask for the next tape in that number sequence.
>>
>> No, nothing about the labeling has any concept of "sequence" with
>> the exception of the date ordering of usage of tapes in the
>> tapelist.
>
>Ah, date order.
>
>> With a suitable labelstr you could leave off the word "tape" and
>> name them 1, 2, ... 13 or with other suitable labelstr you could
>> use one, two, ... thirteen, or presidents names or your children
>> or famous ducks like Huey, Dewey, and Louis.
>
>Yes, I could even change the regex to anything I want.
>
>> > Ok. I will explain this to the client, but I still don't
>> > understand this as different server installs report what tape is
>> > next with amcheck after running one backup, but this one does
>> > not.
>>
>> I don't recall this coming up before so I don't have an answer.
>
>Fair enough.
>
>> > What about a backup not to tape, i.e in the holding disk? I
>> > think i did backup one was done like this. Whould this effect
>> > amcheck?
>>
>> Not certain what you are asking here.
>
>Well, the server that amcheck reports what tape is next, with a
> fresh compile, just like the one in question, had it's first and
> only backup ran with no tape in the drive, only saved in the
> holding disk. This is what I meant.
>
>So, would this have updated the date use date, even though tape1
> wasn't used, amcheck still asks for tape2.
>
>Gavin.
>
Humm, jumping in here, I do believe thats whats happening here when it
overruns the available tapesize set in amanda.conf's definition,
effectively hitting an EOT. Somehow its skipping the next tape in
the sequence on the next run, and I'd bet thats the real problem.
The erronious updating of the tapelist's next entry, making it look
as if its freshly used so it gets skipped. My slotxx's are getting
into a rather scrambled order for this, or a similar reason.
However, if I run a flush operation BEFORE I run an amcheck, then it
doesn't seem to appear. Maybe thats another clue?
There's another bug too, when that happens. It doesn't appear to be
'rewinding' the vtape in the verify phase, and the amverify report
that immediately follows in my script is then 100% error messages,
only if the EOT has been hit. I can manually "rewind" it, then run an
amverify against that slot, and its fine till it hits the end of the
truncated file.
A suggestion to the amanda-hackers (I'm not on that list): In the
vtape situation, commonly its all on one big drive or maybe even a
raid of some kind, so it really wouldn't hurt too much if the
tapesize was checked for EOT only before the opening of the next file
to be written, so that the current file could be written in its
entirety even if it did overrun the tapesize by 500 or more megs
because on a disk it doesn't hurt till the disk is full. That file
would then be written in its entirety, and would not have to be
duplicated, thereby wasting the drive space for the truncated
version. It would in these cases, be an overall plus in better drive
space utilization in the grand scheme of things. Either that, or
delete the unfinished file, in either case saveing that drive space
for usable data in whole files.
With all the data shuffling I've done over the last couple of weeks as
FC3 is about to be released, I'd bet a bottle of suds that more than
5% of my drive is truncated files right now. Thats 5GB!
>- --
>Kind Regards,
>
>Gavin Henry.
--
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)
99.28% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
|
