Bug 1074243

Summary: [abrt] rsync: hash_search(): rsync killed by SIGABRT
Product: [Fedora] Fedora Reporter: smanocch <stefano.manocchio>
Component: rsyncAssignee: Michal Luscon <mluscon>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: mluscon, psimerda, ssorce
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/37a8784177218808bb438f49d0da74bdb1cf2544
Whiteboard: abrt_hash:d6ed478215bf406c9b602c8016e4df52176ba200
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-08-22 11:31:11 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: backtrace
none
File: cgroup
none
File: core_backtrace
none
File: dso_list
none
File: environ
none
File: limits
none
File: maps
none
File: open_fds
none
File: proc_pid_status
none
File: var_log_messages none

Description smanocch 2014-03-09 07:26:10 UTC 
Description of problem:
Doing rsync (using ssh) of a large file (about 100gb) using the following cmd:

rsync -arvHu --delete --progress --stats /develop/Machines/win7/ -e ssh -p 1234 stefano.1.2:/home/stefano/VM/

After a while rsync process occupied 100% cpu and I had to kill it

Version-Release number of selected component:
rsync-3.1.0-2.fc20

Additional info:
reporter:       libreport-2.1.12
backtrace_rating: 4
cmdline:        rsync -arvHu --delete --progress --stats /develop/Machines/win7/ -e 'ssh -p 1234' stefano.1.2:/home/stefano/VM/
crash_function: hash_search
executable:     /usr/bin/rsync
kernel:         3.13.5-200.fc20.x86_64
runlevel:       N 5
type:           CCpp
uid:            1000

Truncated backtrace:
Thread no. 1 (5 frames)
 #0 hash_search at match.c:236
 #1 match_sums at match.c:398
 #2 send_files at sender.c:406
 #3 client_run at main.c:1152
 #4 start_client at main.c:1405
Comment 1 smanocch 2014-03-09 07:26:18 UTC 
Created attachment 872346 [details]
File: backtrace
Comment 2 smanocch 2014-03-09 07:26:20 UTC 
Created attachment 872347 [details]
File: cgroup
Comment 3 smanocch 2014-03-09 07:26:22 UTC 
Created attachment 872348 [details]
File: core_backtrace
Comment 4 smanocch 2014-03-09 07:26:24 UTC 
Created attachment 872349 [details]
File: dso_list
Comment 5 smanocch 2014-03-09 07:26:27 UTC 
Created attachment 872350 [details]
File: environ
Comment 6 smanocch 2014-03-09 07:26:29 UTC 
Created attachment 872351 [details]
File: limits
Comment 7 smanocch 2014-03-09 07:26:32 UTC 
Created attachment 872352 [details]
File: maps
Comment 8 smanocch 2014-03-09 07:26:34 UTC 
Created attachment 872353 [details]
File: open_fds
Comment 9 smanocch 2014-03-09 07:26:36 UTC 
Created attachment 872354 [details]
File: proc_pid_status
Comment 10 smanocch 2014-03-09 07:26:38 UTC 
Created attachment 872355 [details]
File: var_log_messages
Comment 11 Michal Luscon 2014-08-22 11:31:11 UTC 
I think the high cpu load is expected as rsync produces check sums for all blocks of file during transfer. You can try to tweak block size by -B option, or transfer virtual images with --sparse to create new files and consequently use --inplace option for difference synchronization.