--On Thursday, August 15, 2002 11:45:52 -0400 Gene Heskett <gene_heskett AT iolinc
DOT net> wrote:
On Thursday 15 August 2002 11:01, Frank Smith wrote:
--On Thursday, August 15, 2002 11:47:24 +0200 Edwin Hakkennes
<eahakkennes AT xic DOT nl> 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 fsmith AT hoovers
DOT com
Systems Administrator Voice: 512-374-4673
Hoover's Online Fax: 512-374-4501
|
