Hide Forgot
Description of problem: Vanilla F-15 lxde and grsync. I have tried grsync for the first time on F-15, to backup some files on my PC hhd to my USB hdd. The fist time: I generated a kernel crash: Kernel BUG at fs/ext4/inode.c:2188! Invalid opcode: 0000 [#1] SMP The second time: I tried another backup (PC hdd > USB hdd) speed was *very* slow avi. 1.08MB/s (first movie - OKAY) avi. 558.02kB/s (second movie - Warning message) Grsync generated a warning message midway in the second .avi backup, and did not complete the operation (msg): 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) [sender=3.0.8] Rsync process exit status: 12 Version-Release number of selected component (if applicable): Grsync 1.1.1 2.6.38.8-35.fc15.i686 How reproducible: Always Steps to Reproduce: 1. Plug USB HD 2. Backup movie (1 GB) using RSYNC from local hdd to remote USB hdd 3. Actual results: Kernel crash or Grsync warning message Expected results: To backup on my USB HD as it used to be. Additional info: Explain me what command to pass to send the kernel backtrace of the crash as an attachment. When the kernel crash occurred, the bsd? (black screen of the death) msg said: ABRT started. Is the output in var/log, and what file is it? Thanks in advance. # /var/log anaconda cron-20110717 messages-20110710 spooler-20110710 audit cups messages-20110717 spooler-20110717 boot.log dracut.log ntpstats sssd boot.log-20110704 lastlog ppp tallylog boot.log-20110710 lxdm.log prelink wpa_supplicant.log boot.log-20110717 lxdm.log.old secure wtmp btmp maillog secure-20110704 Xorg.0.log btmp-20110701 maillog-20110704 secure-20110710 Xorg.0.log.old ConsoleKit maillog-20110710 secure-20110717 Xorg.9.log cron maillog-20110717 setroubleshoot yum.log cron-20110704 messages spooler cron-20110710 messages-20110704 spooler-20110704
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.