Hi Bernhard,
On Mon, Jun 11, 2001 at 08:45:36AM +0200, Bernhard R. Erdmann wrote:
> I got this snippet from my nightly backup run:
>
> FAILED AND STRANGE DUMP DETAILS:
>
> /-- ente /var lev 1 FAILED [/usr/sbin/xfsdump got signal 6]
> sendbackup: start [ente:/var level 1]
> sendbackup: info BACKUP=/usr/sbin/xfsdump
> sendbackup: info RECOVER_CMD=/usr/sbin/xfsrestore -f... -
> sendbackup: info end
> | xfsdump: version 3.0 - Running single-threaded
> | xfsdump: level 1 incremental dump of ente:/var based on level 0 dump
> begun Sun Jun 10 02:24:35 2001
> | xfsdump: dump date: Mon Jun 11 02:12:27 2001
> | xfsdump: session id: ccc7ce3b-6c3e-49cb-8d3d-7632f8f51040
> | xfsdump: session label: ""
> | xfsdump: ino map phase 1: skipping (no subtrees specified)
> | xfsdump: ino map phase 2: constructing initial dump list
> ? xfsdump: inomap.c:1345: map_add: Assertion `ino > last_ino_added'
> failed.
> sendbackup: error [/usr/sbin/xfsdump got signal 6]
> \--------
>
>
> What's the meaning of "Assertion `ino > last_ino_added' failed"?
In xfsdump it creates an inodemap of the filesystem which basically
is a datastructure which says whether a directory or non-directory
inode has changed or not for the dump.
It creates the inodemap by processing all the inodes of the given xfs
filesystem by making bulkstat calls
i.e. ioctl(fsfd, XFS_IOC_FSBULKSTAT, &bulkreq).
The bulkreq has a buffer and a request for a buffer's worth of
inode stat records.
It is supposed to return the inode stat records in ascending
inode number order.
This assert seems to be indicating that the latest inode it is
processing from bulkstat does not have a greater inode# than
the previous one ! Something wrong here :(
Have you seen this before ?
I can add some more diagnostics so that we can at least know what the
'ino' and 'last_ino_added' values are.
--Tim
|