Alexander Fisher wrote:
The messages probably relate to you dumping an active file system - one
files are being modified/removed as the dump is going on (I didn't look
at your context).
I've mounted my snapshots readonly, but I occasionally get warnings
from xfsdump during the backups. I get two different types of
xfsdump: WARNING: failed to get bulkstat information for inode 10485897
xfsdump: WARNING: could not stat dirent .viminfo ino 10485896: No such
file or directory: using null generation count in directory entry
What's causing these? Can they be ignored?
The first warning happens when we are dumping files and processing
The bulkstat data is the ondisk-inode data (a buffers worth of inodes)
which may not reflect
the latest in-memory data.
For instance, the inode may be being deleted and the link count has been
If dump detects this then it makes another call which effectively gets
data for the inode (bulkstat-single call). When it did this it failed
and so the inode has probably
been deleted. Since the file-system is active, it is reasonable to
notify you about the inode.
In the 2nd case, it is dumping out directory entries (dirents) for a
In the dump of dirents it also stores the inode generation number
(gen#), and since the dirent
structure has the inode# but not the gen#, it does a stat call to get
back the gen#.
When it does this it fails to get the inode, so it uses a value of zero
for the gen#.
In your case .viminfo existed when it read the dirents into the buffer
but then as it
processed each entry and did a stat on the inode for .viminfo, it was no
I almost would have thought it might skip this directory entry.
I presume it stores the gen# because the dumping is done in 2 stages -
dumping of the directory
entries and then dumping of the non-directories (files). And by the time
we come around to
dumping the file (which includes the ino# and gen#) it would be good to
know that this is
the same file as the one referenced in the directory entry and not
another file reusing
the inode#. Using a gen# of zero in this case would likely do the job as
a new inode with the
same inode# will have a non-zero gen# and will not match with this entry.
My 2 cents explanation :)
Anyway, yes, I think they can be ignored.
As these messages have often caused grief, I guess it would be nice if
they were a bit