Re: xfs and lvm snapshots

[tim shimmin <tes@xxxxxxx>]

Hi Alex,

Alexander Fisher wrote:
> Hi again.
>
> I've mounted my snapshots readonly, but I occasionally get warnings
> from xfsdump during the backups.  I get two different types of
> warning.
>
> xfsdump: WARNING: failed to get bulkstat information for inode 10485897
> and
> 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?
>
> Thanks,
> Alex
>
>   
The messages probably relate to you dumping an active file system - one 
where
files are being modified/removed as the dump is going on (I didn't look 
at your context).

The first warning happens when we are dumping files and processing 
bulkstat information.
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 
zeroed.
If dump detects this then it makes another call which effectively gets 
the in-memory
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 
directory.
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 
longer there.
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
more helpful.

--Tim