[Bug 13109] New: rsync hangs during transfer of many small files

[samba-bugs at samba.org]

https://bugzilla.samba.org/show_bug.cgi?id=13109

            Bug ID: 13109
           Summary: rsync hangs during transfer of many small files
           Product: rsync
           Version: 3.1.2
          Hardware: x86
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: core
          Assignee: wayned at samba.org
          Reporter: samba at hlipp.de
        QA Contact: rsync-qa at samba.org

Overview
========

rsync hangs during the transfer of directories containing many small files. The
blocked process must be interrupted or killed and the transfer restarted,
sometimes many times in a row.

As opposed to my previous bug report _this_ time, there are no hard links
required to make rsync hang, only regular files are involved.

How to reproduce
================

[ Using Linux on e.g. ext4, about 3 GiB disk space required ]
############################
mkdir rstest
cd rstest

wget 'http://www.hlipp.de/rs/mktest'
chmod u+x mktest

mkdir files
cd files
wget 'http://www.hlipp.de/rs/1518_0219.jpg_original'
wget 'http://www.hlipp.de/rs/1518_0219.jpg'

cd ..
./mktest 5000
############################

Background: This is based on a larger backup script (which explains the
somewhat odd directory names etc.) that often hangs. The error often occurs
when a user has many image files in a directory which are geotagged (eventually
using exiftool) causing the original files to be renamed to *.jpg_original and
a new file with updated EXIF information to be created. As I don't know if it
is important that only a part of the file changes, I actually include an
example image file into the test case.

The script creates a directory "dst" containing 5000 image files (which
represents an old backup before geotagging) and a directory "src" containing
the same files renamed to *.jpg_original and additionally 5000 image file with
altered EXIF information. Finally,
 rsync -avvHAXSkK --backup --backup-dir="$PWD/X/bak" "$PWD/X/src/."
"$PWD/X/dst/."
is executed.


Actual Results
==============

The transfer starts normally (files are backed up and transferred to the
destination directory, the log looks as expected) but unexpectedly stops
without any message or other hints what is going on. The actual number of files
that are transferred vary from system to system. Recent tests stopped after
1193, 1105, 972, and 1266 files.


Expected Results
================

rsync should not block but complete the transfer.


Further information
===================

This problem exists at least for rsync versions 3.1.0 and 3.1.2 for different
Linux varieties (at least some OpenSUSE versions and Debian jessie) on x86_64
using various file systems (at least ext4 and xfs).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.