Description of problem: ftp of large tar file to a logical volume hangs (never completes). Same tar file can be ftped to a device that is not part of lvm. Version-Release number of selected component (if applicable): AS3.0 platform is s390x. z/VM 4.0 on an IBM 990 zSeries How reproducible: any time Steps to Reproduce: 1. ftp from one VM guest to second VM guest 2. from directory is /dev/dasdf1 3. to directory is /dev/VGtest/testvol Actual results: never completes. must reboot target system Expected results: successful transfer of tar file Additional info:
Could you provide a stack backtrace for the offending task, please? A system-wide trace can be obtained with sysrq-t.
How can I do this on an S/390 guest? I get "command not found" for sysrq and sysrq-t.
"echo -n t > /proc/sysrq-trigger" should do it, thanks.
I have a VM system console for the host that the ftp file was being pulled from, i.e. the originating host. It contains the output from the echo command. I did a control c and closed the ftp session from the second host and then did the same echo command there. I have the VM system console file from the second host. Where do I send the system console files?
Please attach them into bugzilla: there should be a button at the bottom of the bug report for "create a new attachment." Thanks!
Created attachment 96839 [details] trace on host who owns the file; text mode
Created attachment 96840 [details] trace on host attempting to ftp the file D1.tar
Well, on the ftp host all the vsftp daemons are in S mode in the networking stack. There's no sign at all of any LVM activity in there. Likewise on the host doing the ftp client. And the ftp command exited normally according to the log: I don't understand where the "must reboot target system" comes from. Looks like you need an "strace" of the ftp client and server to go much further, but on the face of it the traces here don't show any sign of an LVM-specific problem.
I ran the same ftp test to a non-LVM disk several times. At this point, LVM doesn't seem to be involved. The first receive of a file is successful. The second receive seems to hang at about the half-way mark. All sessions are hung. No activity on the guest can be seen by the VM IND command. I abort the ftp on the client with a control c on the 3270 console (symbol above the numeric 6 followed by c). All sessions recover. Target disk is 2G and at 48% at this time.
Created attachment 96865 [details] sysrq-trigger on client when hung on ftp receive
Very nice trace, but the ^C was entered before the Sysrq-T. We need the Sysrq-T to capture the hanging process. Betsie, please do this: - Before running the ftp, do "echo 8 > /proc/sys/kernel/printk" to raise the log level, do "echo 1 > /proc/sys/kernel/sysrq" to enable sysrq from console. - Run ftp (make sure that it hangs, e.g. wait a little) - Enter ^-t off the start of the line, just like ^c This time, a stack of the ftp should be captured.
Created attachment 96997 [details] client tcpip trace Thank you for the instructions. Trace taken on client.
Everything came out ok, but I'm still confused. The ftp just sleeps while reading from a socket. More thinking is needed.
Created attachment 97045 [details] NT host doing a get from this RH 3.0 Linux Trace taken on Linux host when an NT machine was doing a get of a large tar file.
Created attachment 97046 [details] Linux host doing a put to a Intel Linux host Tried to put the large tar file on an Intel Linux host.
Is this still a problem? I suspect it should be the case, because there were no radical changes to RHEL 3. But is a test case still available?
This bug is filed against RHEL 3, which is in maintenance phase. During the maintenance phase, only security errata and select mission critical bug fixes will be released for enterprise products. Since this bug does not meet that criteria, it is now being closed. For more information of the RHEL errata support policy, please visit: http://www.redhat.com/security/updates/errata/ If you feel this bug is indeed mission critical, please contact your support representative. You may be asked to provide detailed information on how this bug is affecting you.