| Summary: | rsync - IO errors and Kernel crash | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | nomnex <nomnex> | ||||
| Component: | rsync | Assignee: | Vojtech Vitek <vvitek> | ||||
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 15 | CC: | cwickert, hripps, ssorce, vvitek | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | i686 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2011-08-22 10:25:33 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
|
Description
nomnex
2011-07-20 01:29:41 UTC
Pingback forum post with a similar issue http://www.fedoraforum.org/forum/showthread.php?p=1496705 I tested with a rsync command (with minimal option). It was fast and went fine. [mt@nh28d ~]$ rsync -vvr /home/mt/download/KinDzaDza /media/disk2/torrent/movie/ sending incremental file list delta-transmission disabled for local transfer or --whole-file KinDzaDza/ KinDzaDza/kin_dza_dza_1986_part1.avi KinDzaDza/kin_dza_dza_1986_part1.srt KinDzaDza/kin_dza_dza_1986_part2.avi KinDzaDza/kin_dza_dza_1986_part2.srt total: matches=0 hash_hits=0 false_alarms=0 data=1473476623 sent 1473476623 bytes received 92 bytes 19261133.53 bytes/sec total size is 1473296482 speedup is 1.00 This is not a problem with grsync because grsync just calls an rsync command line. This being said when you test grsync vs. rsync, make sure to use exactly the same options. In grsync use 'File -> rsync command line' to figure out the exact command line and then run it on a terminal. Needless to say use exactly the same files. As for the kernel crash it should be in /var/spool/abrt somewhere. Use 'abrt-cli --list' or abrt-gui to find out. I am going to reassign this to rsync itself because it is not caused by grsync. And it doesn't have anything to do with LXDE either, so I adjusted the summary of the bug. Created attachment 515994 [details]
phone photo of the message after kernel crash
According the shell message after the crash, there was an abrt report about the issue, but it was nothing in /var/spool/abrt (only some reports about pyhook at the give date). I have looked in /var/log/messages (nothing there either).
the only info I have at hand is a print screen I took from my phone when the crash occurred (see attachment).
I will try exactly the same command with a same set of files, along next week, as you requested, and post back.
Also try to run rsync in verbose mode (rsync -vvv), please. Seems like you were using EXT4 fs on USB hdd, am I right? What fs was used on the PC hdd? Hi, I did not have time to try a new backup with grsync vs. rsync yet (I am not very handy with the command line and rsync options). I will use the -vvv mode. You are correct, ext4 on the HDD usb and ext4 on the PC, both disks share the same user, permission, etc. I have tried some massive backups PC > USB HDD using rsync/grsync with the same perm. sets and the same files (~100 GB back and forth), and so far, I can't reproduce the bug. There's been no crash. Grsync log output the same as rsync verbose command, speed is similar. I can't say why I've experienced a Kernel panic doing a rsync backup, but I hope it was a one time happening. We don't have enough information, so I can't even say if it was bug in rsync or ext4 kernel code. Imho, the below messages more points to the kernel code.. > rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken > pipe (32) > rsync: write failed on "/media/disk2/torrent/avi/0004.avi": Read-only file > system (30) > rsync error: error in file IO (code 11) at receiver.c(322) [receiver=3.0.8] > rsync: connection unexpectedly closed (70 bytes received so far) [sender] > rsync error: error in rsync protocol data stream (code 12) at io.c(601) > kernel BUG at fs/ext4/inode.c:2188! > invalid opcode: 0000 [#1] SMP > last sysfs file: /sys/devices/pci000... Closing INSUFFICIENT_DATA. Feel free to reopen the bug once you can reproduce the bug again and provide us more information.. Thanks! I will if it happens again. Thanks for the feedback. |