Hi Matteo,
On Mon, Jan 07, 2002 at 09:33:08AM +0100, Matteo Centonza wrote:
>
> these are the logs from last incremental dump through amanda:
>
> FAIL dumper embeh / 1 [/usr/sbin/xfsdump got signal 6]
> sendbackup: start [embeh:/ level 1]
> sendbackup: info BACKUP=/usr/sbin/xfsdump
> sendbackup: info RECOVER_CMD=/bin/gzip -dc |/usr/sbin/xfsrestore -f... -
> sendbackup: info COMPRESS_SUFFIX=.gz
> sendbackup: info end
> | xfsdump: version 3.0 - Running single-threaded
> | xfsdump: level 1 incremental dump of embeh.sif.it:/ based on level 0
> dump begun Fri Jan 4 23:42:11 2002
> | xfsdump: dump date: Sun Jan 6 20:04:26 2002
> | xfsdump: session id: 387c506e-593f-471d-a227-53c37f845c94
> | xfsdump: session label: ""
> | xfsdump: ino map phase 1: skipping (no subtrees specified)
> | xfsdump: ino map phase 2: constructing initial dump list
> | xfsdump: ino map phase 3: pruning unneeded subtrees
> ? xfsdump: inomap.c:858: supprt_prune: Assertion `state != 2' failed.
> sendbackup: error [/usr/sbin/xfsdump got signal 6]
>
> 2.4.14-xfs-1 #2 Fri Nov 9 12:10:19 CET 2001 i686 unknown
> xfsdump-1.1.7-0
> HTH,
> -m
Was the filesystem busy when the dump was going on; in particular,
were files/dirs being created and deleted ?
The reason I ask is because the assertion failure indicates that
the inode map thinks that the inode in question is an unchanged file,
(MAP_NDR_NOCHNG), whereas the recent stat on the file indicates that
the inode is a directory.
The assertion is saying that it can't be a file since my stat indicates
it's a directory.
"xfsdump: ino map phase 2: constructing initial dump list" mentioned
above, is the phase where the inode map is built. The inode map is a
mapping from inode numbers to an 8-value state.
The state indicates whether it is a directory or not and whether the
inode has changed or not (since the last dump) and a few other things.
The state is set after doing a stat on all the inodes (using bulkstat).
So at that point in time xfsdump thought the inode was a non-dir.
Then in the next phase,
"xfsdump: ino map phase 3: pruning unneeded subtrees", it
does more stat'ing and directory path walking to mark certain
subtrees as MAP_DIR_NOCHNG so that they are not dumped - this can
be effected by the -s option and in incremental dumps.
It is while doing this step that it looked up the map to see if the
directory (indicated by the recent stat data) had changed or not
and it found that the inode map reckoned it wasn't a directory.
So it makes one wonder if the inode number has been reused when
the original file was deleted.
The assertion, however, does not seem the right course of action.
Basically we've done stat's on inodes and stored them away.
Then done stat's again and found that the type of inode has changed
and exited (with assertion failure).
I think it is reasonable that there is a window for inode#s to be
reused and we should handle it gracefully.
I'll discuss with colleagues on what the best fix is.
Now if there were no deletions going on then I need to look elsewhere.
Have you seen this happen before ?
Thanks,
Tim.
|