I just copied a file system using xfsdump|xfsrestore
At least 1 new directory had been created on the source during the xfer (took 9+hours -- 7TB), so I wanted to verify I hadn't missed anything. Using rsync:
rsync --version
rsync version 3.1.0 protocol version 31 Capabilities: 64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints, socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace, append, ACLs, xattrs, iconv, symtimes, prealloc, SLP did: rsync -auvnHAX /oDATA/. /DATA/. got back a rather large list of 4 directories and 13708 files!... So wanted to see WHY it wanted to update them, as I thought the full xfsdump/restore should have resulted in an exact copy. Tried : rsync -auvvnHAX /oDATA/. /DATA/. which manpage said would list "why"... it didn't. I got an 84276 line summary, that Showed all of the files... with <filename> is uptodate and <filename> (and nothing else) on lines where it wasn't uptodate. total: matches=0 hash_hits=0 false_alarms=0 data=0 sent 4,482,129 bytes received 8,653,370 bytes 1,142,217.30 bytes/sec total size is 8,329,967,491,093 speedup is 634,156.91 (DRY RUN) I tried -vvv, but didn't see anything in the 596694 line output file that told reasons... Lots of [sender] makefile(xxcxx,*,2) [sender] pusing local filters..(by dir?) recv_filename received 5 names recv_file_list done [receiver] receiving flist for dir 14 but still no reasons (I could be missing them in all all the output, but don't see other types of lines...) Is there some other option now to determine the reason why a file was xfered? -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html