Bug#622160: rsync: 65000 hard links => assertion failure

2015-12-31 Thread Paul Slootman
On Sun 10 Apr 2011, Neal H. Walfield wrote:

> I use storebackup to create daily backups and I mirror these backups
> to a report machine using:
> 
>   rsync --stats -a -z -H --numeric-ids --link-dest=/backup \
> /backup/ bruckner.vpn.huenfield.org:/home/backup/
> 
> During today's run, rsync reported the following errors:
> 
> ERROR 2011.04.10 11:14:45 27930 rsync: link 
> "/home/backup/forster/2011.04.10_06.36.53/neal/src/temp/linux-2.6-2.6.32/debian/build/build_i386_none_486/include/config/dvb/s5h1409.h"
>  => forster/2011.03.10_11.11.28/.gksu.lock failed: Too many links (31)
> ERROR 2011.04.10 11:14:45 27930 rsync: link 
> "/home/backup/forster/2011.04.10_06.36.53/neal/src/temp/linux-2.6-2.6.32/debian/build/build_i386_none_486/include/config/early/printk.h"
>  => forster/2011.03.10_11.11.28/.gksu.lock failed: Too many links (31)

> I'd like rsync to not fail.  Perhaps it should create an additional
> copy of the content.



On Thu 16 Oct 2014, Jonathan David Amery wrote:
> 
> 
>  It appears that this may have improved slightly since 2011 -- there's
> no longer an assertion failure
> 
>  My backups do: 
> 
>  rsync --archive --sparse --numeric-ids --compress \
>  --fuzzy --hard-links --delete --quiet --one-file-system \
>  --link-dest=/mnt/backups/internal/ivanova/aleph/2014-10-15 \
>  ivanova:/mnt/aleph/. /mnt/backups/internal/ivanova/aleph/2014-10-16/.
> 
>  and today I got the error:
> 
> rsync: link 
> "/mnt/backups/internal/ivanova/aleph/2014-10-16/./home/jdamery/dev/projects/buildit/lis2las/rfid.o"
>  => home/jdamery/dev/projects/buildit/addcurve/rfid.o failed: Too many links 
> (31)

>  When it has this link failure rsync should make a new copy of the file
> exactly as if it had been unable to find a file to link in the first
> place.


In my testing today it seems that this does not go wrong anymore and a
new copy of the file is indeed created; here's the relevant strace
output that shows the link() call failed and subsequently a new file was
created:

[pid 24011] lstat("b", 0x7ffcc58574a0)  = -1 ENOENT (No such file or directory)
[pid 24011] lstat("/tmp/d/linkdest/./b", {st_mode=S_IFREG|0644, st_size=9, 
...}) = 0
[pid 24011] link("/tmp/d/linkdest/./b", "b") = -1 EMLINK (Too many links)
[pid 24011] open(".b.Tnq0GH", O_RDWR|O_CREAT|O_EXCL, 0600) = 0
[pid 24011] fchmod(0, 0600) = 0
[pid 24011] open("/tmp/d/linkdest/./b", O_RDONLY) = 4
[pid 24011] read(4, "contents\n", 8192) = 9
[pid 24011] write(0, "contents\n", 9)   = 9
[pid 24011] read(4, "", 8192)   = 0
[pid 24011] close(4)= 0
[pid 24011] close(0)= 0
[pid 24011] lstat(".b.Tnq0GH", {st_mode=S_IFREG|0600, st_size=9, ...}) = 0
[pid 24011] utimensat(AT_FDCWD, ".b.Tnq0GH", {UTIME_NOW, {1451558126, 
485533088}}, AT_SYMLINK_NOFOLLOW) = 0
[pid 24011] chmod(".b.Tnq0GH", 0644)= 0
[pid 24011] rename(".b.Tnq0GH", "b")= 0


If you still have problems please reply to the bug report so that I can
investigate further. Otherwise I will close this bug soon.


thanks,
Paul



Bug#622160: rsync: 65000 hard links => assertion failure

2015-12-31 Thread Jonathan David Amery
Paul Slootman  wrote:
>If you still have problems please reply to the bug report so that I can
>investigate further. Otherwise I will close this bug soon.
>
 Hi Paul,

 I no-longer have the problematic files in my backup-set so haven't been
encountering the problem recently; but it is good to hear that it has
been addressed.

 Thanks for investigating; and feel free to close the bug as far as I'm
concerned. 

 J.



Bug#622160: rsync: 65000 hard links = assertion failure

2014-10-16 Thread Jonathan David Amery

 It appears that this may have improved slightly since 2011 -- there's
no longer an assertion failure

 My backups do: 

 rsync --archive --sparse --numeric-ids --compress \
 --fuzzy --hard-links --delete --quiet --one-file-system \
 --link-dest=/mnt/backups/internal/ivanova/aleph/2014-10-15 \
 ivanova:/mnt/aleph/. /mnt/backups/internal/ivanova/aleph/2014-10-16/.

 and today I got the error:

rsync: link 
/mnt/backups/internal/ivanova/aleph/2014-10-16/./home/jdamery/dev/projects/buildit/lis2las/rfid.o
 = home/jdamery/dev/projects/buildit/addcurve/rfid.o failed: Too many links 
(31)

 although in my case my maximum is 32000

cleopatra:~# ls -l 
/mnt/backups/internal/ivanova/aleph/2014-10-15/./home/jdamery/dev/projects/buildit/lis2las/rfid.o
-rw-rw-r-- 32000 jdamery 2001 37252 Jan  8  2008 
/mnt/backups/internal/ivanova/aleph/2014-10-15/./home/jdamery/dev/projects/buildit/lis2las/rfid.o

 When it has this link failure rsync should make a new copy of the file
exactly as if it had been unable to find a file to link in the first
place.

J.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#622160: rsync: 65000 hard links = assertion failure

2011-04-10 Thread Neal H. Walfield
Package: rsync
Version: 3.0.7-2
Severity: normal

I use storebackup to create daily backups and I mirror these backups
to a report machine using:

  rsync --stats -a -z -H --numeric-ids --link-dest=/backup \
/backup/ bruckner.vpn.huenfield.org:/home/backup/

During today's run, rsync reported the following errors:

ERROR 2011.04.10 11:14:45 27930 rsync: link 
/home/backup/forster/2011.04.10_06.36.53/neal/src/temp/linux-2.6-2.6.32/debian/build/build_i386_none_486/include/config/dvb/s5h1409.h
 = forster/2011.03.10_11.11.28/.gksu.lock failed: Too many links (31)
ERROR 2011.04.10 11:14:45 27930 rsync: link 
/home/backup/forster/2011.04.10_06.36.53/neal/src/temp/linux-2.6-2.6.32/debian/build/build_i386_none_486/include/config/early/printk.h
 = forster/2011.03.10_11.11.28/.gksu.lock failed: Too many links (31)
...
ERROR 2011.04.10 11:14:45 27930 rsync: hlink.c:537: finish_hard_link: 
Assertion `(((unsigned char *)(node-data))[0]) == 0' failed.

Looking at .gksu.lock, we see that it indeed has the maximum number of
allowed hard links (it also has 0 size):

$ ls -l /home/backup/forster/2011.03.10_11.11.28/.gksu.lock
-rw-r--r-- 65000 neal neal 0 Sep 28  2007 
/home/backup/forster/2011.03.10_11.11.28/.gksu.lock

I'd like rsync to not fail.  Perhaps it should create an additional
copy of the content.

Thanks.


-- System Information:
Debian Release: 6.0
  APT prefers squeeze-updates
  APT policy: (500, 'squeeze-updates'), (500, 'stable')
Architecture: armel (armv5tel)

Kernel: Linux 2.6.32-5-kirkwood
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages rsync depends on:
ii  base-files  6.0  Debian base system miscellaneous f
ii  libacl1 2.2.49-4 Access control list shared library
ii  libc6   2.11.2-10Embedded GNU C Library: Shared lib
ii  libgcc1 1:4.4.5-8GCC support library
ii  libpopt01.16-1   lib for parsing cmdline parameters
ii  lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip

rsync recommends no packages.

Versions of packages rsync suggests:
ii  openssh-client1:5.5p1-6  secure shell (SSH) client, for sec
ii  openssh-server1:5.5p1-6  secure shell (SSH) server, for sec

-- no debconf information




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org