On Fri, 2003-11-21 at 16:17, Guus der Kinderen wrote:
I used a similar set at the sender-side ( $ udp-sender --pipe "dd if=/dev/hda1/" ), 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 issue.
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 look for any hints in the output of 'ulimit -a'.