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@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
