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?
- Guus
At 19:44 21-11-2003, Dylan Martin wrote:
Oops. Sorry about the empty email... Achem!
Anyway, I was going to say, we had the same problem, but we fixed it by piping through dd. Our problem seemed to be on the sender though... here's what we did...
udp-sender --nokbd --max-bitrate 80m --pipe "dd if=/home/image/disk.img"
The nokbd and max-bitrate are for unrelated problems...
Maybe some simler dd trickery would help your problem.
-Dylan
Hi everybody, I have problem with udp-receiver, it is unable to store files larger than 2GB. I have read older post and found some work around (udp-receiver > image.gz) but this did not work either.
my config is: CPU P4 2,4GHz, RAM 512 DDR, HDD WD 120GB, NIC RTL8139 (8139too driver), i run debian woody orignaly (2.2) kernel but i upgraded to 2.4.18-686, i use udpcast 20030831, partition where i store image i big enough and has reiserfs
i administer small lan, about 15 winxp boxes
any hints?
thanx, der3k
Udpcast mailing list Udpcast@udpcast.linux.lu http://udpcast.linux.lu/mailman/listinfo/udpcast
I could be totally wrong about our problems being similer, but involving dd and a pipe did seem to convince something not to interfere. I think once it stopped having a defined size and became a stream of bits, something calmed down. I'd try piping the output to dd and see if it helps. I see you're using reiserfs. I know next to nothing about that FS, but maybe there's some obscure settings you need to tweak. Can you try other FSs? I wasn't using a file system at all on my recieving computers, just blowing the image straight to /dev/hda5 or something. In my case the image was OSX, the server was Redhat on i386 and the reciever was Yellowdog on mac hardware.
-Dylan
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?
- Guus
At 19:44 21-11-2003, Dylan Martin wrote:
Oops. Sorry about the empty email... Achem!
Anyway, I was going to say, we had the same problem, but we fixed it by piping through dd. Our problem seemed to be on the sender though... here's what we did...
udp-sender --nokbd --max-bitrate 80m --pipe "dd if=/home/image/disk.img"
The nokbd and max-bitrate are for unrelated problems...
Maybe some simler dd trickery would help your problem.
-Dylan
Hi everybody, I have problem with udp-receiver, it is unable to store files larger than 2GB. I have read older post and found some work around (udp-receiver > image.gz) but this did not work either.
my config is: CPU P4 2,4GHz, RAM 512 DDR, HDD WD 120GB, NIC RTL8139 (8139too driver), i run debian woody orignaly (2.2) kernel but i upgraded to 2.4.18-686, i use udpcast 20030831, partition where i store image i big enough and has reiserfs
i administer small lan, about 15 winxp boxes
any hints?
thanx, der3k
Udpcast mailing list Udpcast@udpcast.linux.lu http://udpcast.linux.lu/mailman/listinfo/udpcast
Udpcast mailing list Udpcast@udpcast.linux.lu http://udpcast.linux.lu/mailman/listinfo/udpcast
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'.
On Fri, Nov 21, 2003 at 05:26:08PM -0700, Dave King wrote:
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?
updcast probably needs to open the target file w/ O_LARGEFILE.
-
dann frazier -
Dave King -
Dylan Martin -
Guus der Kinderen