[Top] [All Lists]

Re: xfsdump error question

To: Russel Ingram <ringram@xxxxxxxxxxxxxx>
Subject: Re: xfsdump error question
From: ivanr@xxxxxxxxxxxxxxxxx (Ivan Rayner)
Date: Tue, 11 Sep 2001 15:49:18 +1000
Cc: <linux-xfs@xxxxxxxxxxx>
In-reply-to: <20010910114627.A1640@xxxxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
On Mon, 10 Sep 2001, Russel Ingram wrote:

> xfsdump: calling bulkstat
> xfsdump: bulkstat returns buflen 4096 ino 5282011
> xfsdump: ino 5768703 needed second bulkstat
> xfsdump: ERROR: map_add(5243008, 3): ino(5243008) <= last_ino(5768702)
> Can someone tell me what this error means and if its something I'm
> doing wrong or if its a problem with my filesystem or xfsdump?
> I've also attached the output from running the same command with -v5.

When xfsdump does a bulkstat to get the stat information for a whole bunch
of files, it can sometimes detect inconsistencies which usually means the
inode is or has just been modified.  xfsdump will then call
bulkstat_single to reget this information.

In your case, xfsdump tried to reget the stat information for inode
5768703 but it got back information for inode 5243008.  This is a problem.
Looking at the code, the bulkstat_single probably would have returned an
errno, but xfsdump doesn't check the return value for the ioctl, and it
continues to process the stat info, but dies when it realises that it
shouldn't have an ino which is out of sequence.

So, the question is, is there a problem with your filesystem?

Can you do a:

    # find / -inum 5243008 -o -inum 5768703

to see which files these inode numbers represent?

In the xfstests package, there is a program called bstat.  It will go
through a filesystem comparing what it gets from bulkstat with regular
stat information.  You should redirect it's output to a file ...  there
will be alot of it:

    # bstat -C -l 5243000 > bstat.log

When it's done, take a look at the bstat.log to see if there are any
inconsistencies with inodes 5243008 and 5768703.

It might also be interesting to see the inode information from xfs_db:

    # xfs_db -r /dev/<root_device>
    xfs_db: inode 5243008
    xfs_db: p
    xfs_db: inode 5768703
    xfs_db: p

And I suppose you could remount your root filesystem readonly and run
xfs_repair and see what it produces.


Ivan Rayner

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