On Wednesday 16 March 2005 14:12, John Stange wrote:
>Been taking a look at amverify, having been asked to make it
> cooperate with the spanning tape patch. The thing that causes it
> to not work, however, brings up something of a dilemma...
>
>amverify invokes amrestore on a set of tapes, checking headers for
> sanity and even testing with the restore utility to lend some
> confidence to data integrity (at least, that's my understanding of
> it). The issue that crops up with split dumps is that an
> individual dump file on tape won't necessarily be a complete
> dump/tar file, and thus will be detected as bogus when tar or
> restore chokes on the data.
>
>My first instinct for a fix would be to have amverify skirt the
> issue by making note that a dump file on tape is, in fact, a small
> part of a larger logical dump, and not trying to check it with
> tar/restore. But, it can't make that distinction! Because
> amrestore deliberately rewrites the dump header when invoked with
> -h to hide split dumps. This is for amrecover's benefit, as an
> unpatched version will freak out at the sight of an unfamiliar
> header.
>
>So, the options, as I see them:
>
>- Add yet another option to my patched version of amrestore that's
> "-h, only without the header mangling that we do for amrecover
> backwards-compatibility." This adds option clutter, but is also
> really easy.
>
>- Ditch the idea of letting unpatched amrecover clients cooperate
> with spanning-supporting servers. While undoing all of the
> horrendous hacks I had to do to make this work isn't without its
> appeal, backwards compatibility is everyone's friend. Also that
> sounds like work.
>
>- Make amverify use amfetchdump instead of amrestore, which will
> both circumvent this problem and allow to more thoroughly sanity
> check split dumps (a failed reassembly would be a nice thing to
> check for).
This sounds like the best option, however I'm not familiar enough with
the differences in the two utilities to be able to make a very
intelligent judgement one way or the other. Recoverywise, I could
just as easily dd the two pieces off the storage media, then cp
file_one file_two file_three, then unpack file_three. All to a
scratch area. So one shouldn't be married to a single way of doing
it, using instead whatever works.
I saw a phrase in a sig the other day that said "even if its not
right, if it works, then its correct", which has more than a passing
resemblance to the ring of truth.
>- It may also be possible to insert something between the amrestore
> pipe to amrecover in amidxtaped that does the header mangling,
> obviating the need for this to be span-patched amrestore's default
> behavior. This sounds like a revolting hack, not that the
> amrecover compatibility workarounds aren't already gross.
I think I'd go for the most 'correct' of the options, while defineing
'most' correct as being zero disturbance to existing, non-spanning
installs that will of course need to maintain their database
compatibility across the upgrade if indeed thats what we call it.>
>Opinions?
I'm ambivelant except for the prerequisite of direct, step by step
instructions in the docs for the gnubees (or old bees in my case).
Not to mention good explanatory comments in the code itself so the
next person to walk thru there knows exactly what was on your mind
when you wrote it.
--
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.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
|
