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
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
never completes. must reboot target system
successful transfer of tar file
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
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:
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.