[Top] [All Lists]

Re: xfsdump assertion failure

To: Timothy Shimmin <tes@xxxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: xfsdump assertion failure
From: Matteo Centonza <matteo@xxxxxx>
Date: Wed, 9 Jan 2002 09:38:57 +0100 (CET)
Cc: <linux-xfs@xxxxxxxxxxx>
In-reply-to: <20020109175926.Y1500056@boing.melbourne.sgi.com>
Sender: owner-linux-xfs@xxxxxxxxxxx
Hi Tim,

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.



<Prev in Thread] Current Thread [Next in Thread>