thanks for your response.
> > 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 command was cron issued last sunday around 8 p.m., when there's little
or no activity, but it's a root filesystem....
> 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.
Yes, it's very unlikely given the very mild load and the mean dump
duration (less than 2 mins).
> 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 ?
No. We've had only annoying bulkstat ever once in a while.
The next incremental is scheduled for this evening.