On Mon 07 Mar 2016, John Lewis wrote: > > > > Also, the rsync display this error message: > > > > > > sent 1396995175 bytes received 3402980 bytes 5215635.59 bytes/sec > > > total size is 1809788032 speedup is 1.29 > > > rsync error: some files/attrs were not transferred (see previous errors) > > > (code 23) at main.c(1070) [sender=3.0.9] > > > > > > What I'm doing wrong? > > > > Run it again at this point, you should see just the failing parts. > > > > I run it again as your suggestion. Here is the message: > > rsync: link > "/usr/home/john/dirvish/dirvish/www/2016-03-07/tree/etc/sgml/catalog" => > dirvish/www/2016-03-05/tree/etc/sgml/catalog failed: No such file or > directory (2)
This is strange, rsync has detected that the etc/sgml/catalog file is the same on 2016-03-07 as it was on 2016-03-05, but that 2016-03-05 version isn't there (anymore)? Check those files on the source and the destination and see if all instances exist and whether they're hardlinked or not. > I guess the error is not a problem. What confuse me is the filesize that > have a huge different. Well, the error is indicative of some problem; I'm guessing this leads to these file not being hard-linked, although these are small files, not 500GB (the difference in size you're seeing) at least... On Mon 07 Mar 2016, Dave Howorth wrote: > On 2016-03-07 13:22, John Lewis wrote: > > On Mon, Mar 7, 2016 at 7:12 PM, Dave Howorth > > <[email protected]> wrote: > > > >> Filesystem type can make a difference. > > > > The local host is running Linux with filesystem ext2 or ext4. The > > remote server is running FreeBSD, but I cant determine what is the > > filesystem :( > > Sorry, I don't know anything about FreeBSD. But that could well account > for some of the difference, perhaps all. If you can find a reasonably large subdirectory somewhere without symlinks, you could compare the 'du' of the source and destination versions to see whether that differs much. If so, then the difference is explained. > >> Also, have you checked a sample of the hardlinks to make sure that > >> they do actually match on the local and remote now? > > > > Could you please show me what do you mean by this and how to check > > it? > > Just do an ls -l of each and check the link count (i.e. second field) is > the same on the source and destination. I'd do: find topdir -type f -links +1 -ls or find topdir -type f -links +1 -printf '%9i %3n %9s %p\n' which will just print those files with more than one link, and in the latter case will output the inode number, number of links, filesize, and filename (the %9 indicates the width of the column should be at least 9, in an attempt to make it line up). Whether this works on *BSD is left as an exercise for the reader :) If not: find topdir -type f -links +1 -print0 | xargs -0 ls -li Paul _______________________________________________ Dirvish mailing list [email protected] http://www.dirvish.org/mailman/listinfo/dirvish
