On Fri, 2003-11-21 at 16:17, Guus der Kinderen wrote:
I used a similar set at the sender-side ( $ udp-sender
but I don't see why the way how you send stuff affects the maximum storage
size on the receivers end. Can anyone think of something?
I used to have similar problems with a busybox gzip which either
couldn't receive more than 2^31 bytes via pipe, or couldn't append that
much to a file. It would always break around 2GB. I don't recall exactly
why, and didn't look closely because I worked around it by switching to
a full version of gzip. It seemed similar to the original poster's
At the time I was running udpcast inside the %pre section of a RedHat
anaconda kickstart install. That's why my default gzip was a busybox.
I don't know enough to speculate intelligently, but I'll try anyway:
Maybe the sender was sending a whole lot of compressed zeroes which the
receiver can't write to disk fast enough, resulting in a full pipeline
which one side or the other handles poorly.
I would try booting into the udp-receive environment and verify that it
is even possible to create a >2GB file on the target volume within that
environment (kernel & shell) using 'cat /dev/zero > zero'. I'd also
for any hints in the output of 'ulimit -a'.