2012/2/18 Bill Kendall <wkendall@xxxxxxx>: > On 02/14/2012 11:21 AM, Tommy Wu wrote: >> >> from the xfsdump man page: >> xfsrestore also generates a directory named orphanage in the dest >> directory. xfsrestore removes this directory after completing a simple >> restore. However, if orphanage is not empty, it is not removed. This >> can happen if files present on the dump media are not referenced by >> any of the restored directories. The orphanage has an entry for each >> such file. The entry name is the file's original inode number, a ".", >> and the file's generation count modulo 4096 (only the lower 12 bits of >> the generation count are used). >> >> and the -t option from xfsdump man page: >> Displays the contents of the dump, but does not create or modify any >> files or directories. It may be desirable to set the verbosity level >> to silent when using this option. >> >> But when we use -t option with xfsrestore, it still create orphanage >> directory in current directory (because no dest directory assign). >> and if it's not empty, it is not removed. >> >> This is a bug or it's a feature? > > > I can see code where this would happen, except that it would appear > to require both -r and -t to be used, and xfsrestore doesn't allow > that. > > If you send the command line you used I can take another look. > > Bill here is the command I used for -t: cat var.xfsdump.gz | gzip -dqv | xfsrestore -v silent -p 300 -J -t - | grep "^xfsrestore:" I also test it with only -t option, it also create orphanage folder for such dump file (not all dump file has this issue) cat var.xfsdump.gz | gzip -dqv | xfsrestore -t - | grep "^xfsrestore:" -- Tommy Wu _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
