--On Thursday, August 15, 2002 11:45:52 -0400 Gene Heskett <[EMAIL PROTECTED]>
wrote:
> On Thursday 15 August 2002 11:01, Frank Smith wrote:
>> --On Thursday, August 15, 2002 11:47:24 +0200 Edwin Hakkennes
> <[EMAIL PROTECTED]> wrote:
>>> Hi all,
>>>
>>> I added a 'big' disk to my disklist yesterday. About 8G.
>>> Flushing the files from the holding disk results in
>>>
>>> NOTES:
>>> amflush: beosrv-1._redhat.0.2: ignoring cruft file.
>>> amflush: beosrv-1._redhat.0.3: ignoring cruft file.
>>> taper: tape xic03 kb 13511296 fm 58 [OK]
>>>
>>> Should I worry about this? Did only 2G of the backup actually
>>> make it to the tape?
>>
>> It wrote 13.5G to tape, and according to your output below, 7.6G
>> of that was from your "beosrv-1 /redhat" disklist entry. I think
>> the cruft file messages are just a result of the somewhat
>> asynchronous nature of amanda. The chunk files are removed after
>> each set is written to tape but may not be all gone yet when
>> Amanda scans for other chunk sets to flush to tape. Anything
>> that it doesn't know what to do with is reported as 'cruft',
>> whether it is some odd file put in the holding disk or a chunk
>> that isn't part of a complete set (the chunk files are named as
>> host.filesystem.level.chunknumber).
>> 'Notes' are just informative, 'strange' needs to be examined, it
>> may or may not be a problem, and 'warning' you better pay
>> attention to.
>>
>> Frank
>
> Hummm, this brings up an interesting thought, Frank.
>
> If amanda removed the chunk files as they were written, then how
> would amanda go about the case of hitting EOT in the middle of the
> last chunk file, finding that it has perms (via runtapes>=2 for
> instance) to use the next tape in the magazine, at which point
> amanda supposedly restarts that disklist entries dump from the top.
> If there were 4 chunk files, 3 of which had been written and deleted
> when this occured, it seems to me that amanda would find herself
> between a rock and a hard place to be able to restart that
> particular disklist entries dump. It certainly wouldn't be very
> time efficient to redo the whole entry although that does seem to
> be the only way to recover.
>
> So how is this scenario resolved by amanda?
I said that the chunks were removed after the set was written. I
haven't looked at that part of the code, just observed my holding disk
in various situations, so I may not be completely correct. It appears
that after all of the set of chunks belonging to a single disklist entry
are successfully flushed to tape, those chunks are deleted from the disk.
If a tape error occurs anytime during the flush of a set of chunks
all of that set remains on disk so a subsequent amflush can start over
with the first chunk of the set.
I believe Edwin's 'notes' was the result of Amanda successfully
flushing all of the chunks of his 'redhat' directory, but after taper
returned ok a command was given to remove those chunks while amflush
went ahead and rescanned the holding disk looking for anything else
that needed to be flushed. Since it can take a second or two to
remove large files, a couple of the chunks were still there when the
scan occurred, but since the first chunk was already gone Amanda
saw the other two as cruft. Of course, when Edwin looked at the disk
later it was all gone by then.
Frank
> --
> Cheers, Gene
> AMD K6-III@500mhz 320M
> Athlon1600XP@1400mhz 512M
> 99.11% setiathome rank, not too shabby for a WV hillbilly
--
Frank Smith [EMAIL PROTECTED]
Systems Administrator Voice: 512-374-4673
Hoover's Online Fax: 512-374-4501
