Here is the response from support:
---------------------------------------------------------
I've gotten an explanation from development for the image header file
behavior you've been seeing.
When image files are updated in a way that reduces the size of the file, we
pad the file with spaces to the original size of the file. This occurs, for
example, when a copy expires and the fragments for the copy are removed from
the fragment list. With lifecycle processing this is probably happening
more frequently. When we pad the file with spaces, we aren't adding a new
line character at the end. We don't intend for the image header files to be
manually edited, and the warning message doesn't prevent it in any case.
Please let me know if this explanation is satisfactory, or if you would be
interested in entering an enhancement request to get a newline added.
-----------------------------------------------------------
I've suggested that since customers are sometimes asked to make changes to
the header files by support, two things should happen:
1) This behavior should be clearly documented.
2) The padding should be properly terminated with a newline character.
I'll let you know if this goes anywhere.
Anyway, thanks to everyone who helped me out with this.
Neil
On 4/27/09 12:04 PM, "Ron Jack (Systems Network)" <rjack AT nando DOT com>
wrote:
> 6.0 MP4 on Solaris 9. 1 hit out of 7700 "FULLS".
>
> hth.
>
>
> Conner, Neil wrote:
>> Bob,
>> Thanks for the confirmation. I would have been very surprised if there was
>> something that unique about my installation.
>>
>> Maybe it's nothing to be concerned but I'm not willing to just assume that.
>> I've asked to have my case escalated and I'll let you know what I find out.
>>
>> Neil
>>
>>
>>
>> On 4/24/09 12:49 PM, "bob944" <bob944 AT attglobal DOT net> wrote:
>>
>>>> ------ Forwarded Message
>>>> From: "Conner, Neil" <neil AT mbari DOT org>
>>>> Date: Thu, 23 Apr 2009 16:55:19 -0700
>>>> To: Veritas List <veritas-bu AT mailman.eng.auburn DOT edu>
>>>> Conversation: Corrupt header files
>>>> Subject: [Veritas-bu] Corrupt header files
>>>>
>>>> Netbackup 6.0 MP5 on Solaris 10.
>>>>
>>>> I was working with support and they had me edit some header files
>>>> and I
>>>> happened to stumble upon one that had some corruption in it: I got
>>>> the
>>>> following error when I opened it with vi:
>>>>
>>>> "client_1212199228_FULL" [Incomplete last line]
>>>>
>>>> I found that an extra line of white space had been tacked on at
>>>> the bottom
>>>> of the file, but it was missing the EOL character. So I wrote a
>>>> script to
>>>> look for more occurrences and I was shocked to find that over a
>>>> third of my
>>>> header files have this extra garbage line in them, and they are
>>>> still being
>>>> created. I?ve got over 13,000 corrupt header files for full
>>>> backups alone.
>>>>
>>>> Restores from the corrupt header files are successful, with or
>>>> without the
>>>> extra line of garbage (which is why it has gone undetected until
>>>> now). At
>>>> this point, support is telling me to either live with it or fix
>>>> all the
>>>> corrupt files, but so far at least, they have not tried to address
>>>> the root
>>>> cause and I?m not satisfied with that. So I?m wondering if anyone
>>>> else has
>>>> a similar issue.
>>>>
>>>> Here is the script (it only samples full backups so it runs
>>>> faster). Update
>>>> the path to the image database if necessary and you can run it
>>>> from
>>>> anywhere.
>>>>
>>>> #!/bin/ksh
>>>> #
>>>> # Check for corrupt header files:
>>>> # These will have white space at the end of a line.
>>>> # grep ?l (ell) produces a list of files instead of a bunch of
>>>> white space.
>>>> #
>>>> ImageDB=/usr/openv/netbackup/db/images
>>>>
>>>> for DIR in `ls -R | find $ImageDB -type d`
>>>> do
>>>> grep -l " \$" $DIR/*FULL 2>/dev/null
>>>> done
>>>>
>>>> I?d be grateful if some of you would run this against your
>>>> catalog. If you
>>>> get any hits, try to edit one of the files and see if you get an
>>>> ?Incomplete
>>>> last line? error.
>>> Neil - I can confirm the extra spaces. In a test domain, I found
>>> 10% of metadata files ended with a line of one or three spaces; the
>>> last good line being either VM_TYPE or LAST_BIRTHTIME which always
>>> have an even number of characters. I checked incrementals and they
>>> have the same thing.
>>>
>>> Opening them with vi, I do get an "incomplete last line," When I
>>> "G" I'll be on a line comprised of one or three spaces.
>>>
>>> I don't see an obvious pattern. I see it on hot catalog, standard
>>> and windows-nt policies, in diff and full schedules. I have
>>> instances from August,08 through this month (and I don't have any
>>> older backups here so August may be only a limitation on my data.
>>> All backups were done on either 6.5.1 or 6.5.3.1.
>>>
>>>
>>
>> _______________________________________________
>> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
>> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
