xfsrestore report SUCCESS but not restore all files in kernel 3.17

[Dave Chinner]

On Wed, Oct 29, 2014 at 12:06:10PM +0800, Tommy Wu wrote:
> /sbin/xfsrestore: session id: 6f114712-6fb6-4f35-a2f3-30ca1a0af5bb
> /sbin/xfsrestore: media id: 2eb2ff54-1838-47b2-a8d5-5f520deaf5f5
> /sbin/xfsrestore: searching media for directory dump
> /sbin/xfsrestore: reading directories
> /sbin/xfsrestore: 2035 directories and 33045 entries processed
> /sbin/xfsrestore: directory post-processing
> /sbin/xfsrestore: reading non-directory files
> /sbin/xfsrestore: NOTE: ino 144 salvaging file, placing in
> orphanage/143.0/Makefile
> /sbin/xfsrestore: NOTE: ino 145 salvaging file, placing in
> orphanage/143.0/bayer.png.b64
.....
> .... skip it....
> /sbin/xfsrestore: NOTE: ino 50363235 gen 1622742662 not referenced: placing
> in orphanage

FWIW, this can be expected behaviour if you run xfsdump on a live
filesystem. From the DIAGNOSTICS section of the xfsdump man page:

	The message ``xfsdump: WARNING: unable to open directory:
	ino N: Invalid argument'' can occur with filesystems which
	are actively being modified while xfsdump is running.
	This can happen to either directory or regular file inodes -
	affected files will not end up in the dump, files below
	affected directories will be placed in the orphanage
	directory by xfsrestore.

This is exactly what you are seeing - files being placed in the
orphanage on restore because they appear to have no parent directory
inode referencing them.

IOWs, you're likely seeing the effect of the filesystem changing
while you are running xfsdump, not a bug in xfsdump or xfs_restore.

Cheers,

Dave.
-- 
Dave Chinner
david at fromorbit.com