> > xfsdump uses an xfs feature called bulkstat'ing to speed up
> > the stat'ing of all the inodes of the file system.
> > However, it apparently snapshots the info from the disk blocks
> > instead of going through the in-core data structures.
> > This means that if this data is not flushed to disk completely
> > when xfsdump is running then it won't have the latest stat
> > information.
> Hmmm... I see.
I should expand on this one a little. XFS has two copies of the inode, first
the in memory inode structure which is used to by most parts of the filesystem,
and is the structure modified by most operations and recorded into the log.
Second is the on disk inode structure which is held in buffers, this structure
is updated asynchronously from the in memory inode and flushed out to disk.
It is this second structure which bulkstat reports the contents of and
hence the potential time lag between what is visible to xfsdump and what is
visible by the regular system call interface. The contents of the inode buffers
should not lag behind the in memory inodes by very much - 30 to 60 seconds with
the default kupdated configuration.
As Ivan pointed out, xfsdump is not an instantanous operation anyway, it takes
time to dump a filesystem, and should the filesystem be changing during the
dump process there is no guaranteed way to ensure that everything which existed
in memory at the time of the end of the dump will be in the dump. However,
everything skipped by one dump should be included in the next dump.