L. A. Walsh
2014-Aug-09 17:41 UTC
meta bug: info on "why" xfer seems no longer available? (3.1.0)
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 --versionrsync 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?
Kevin Korb
2014-Aug-09 21:35 UTC
meta bug: info on "why" xfer seems no longer available? (3.1.0)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 You want less -v and more --itemize-changes. --verbose is utterly useless without --itemize-changes. On 08/09/2014 01:41 PM, L. A. Walsh wrote:> 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? > > >- -- ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ Kevin Korb Phone: (407) 252-6853 Systems Administrator Internet: FutureQuest, Inc. Kevin at FutureQuest.net (work) Orlando, Florida kmk at sanitarium.net (personal) Web page: http://www.sanitarium.net/ PGP public key available on web site. ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlPmlA4ACgkQVKC1jlbQAQeJ9gCgtVyzz1Ps4pECa7JFRiunq3Hd A6UAoLhDpONjrI5h6XP01EMQvGVjEjut =vess -----END PGP SIGNATURE-----