Hubert,
Changing bs=1m didn't solve the problem...the script still runs at the same
transfer rates...
i've been trying different block sizes and different gzip options, but it
seems to make no difference...
Thanks for help anyway.
I'd appreciate if you have more suggestions...
Fernando M. Witzke
2007/10/4, Hubert Feyrer <[EMAIL PROTECTED]>:
>
> On Thu, 4 Oct 2007, Fernando Witzke wrote:
> > I've already tried to add GZIP=1 to the front and the result is the
> > same...it stands around 100~160Kb/s
> > i can't understand it because the uploadpart transfer rate stops arround
> > 12MB/s (the maximum speed i can get at my network), so the local copy
> should
> > at least do it at the same transfer rate, or not?
> > if you have some idea about it please reply...
>
> Well, look at the script - it uses 512 *byte* blocks - that sure asks for
> sucky performance. I forgot why i used such a bad block size... change
> bs=512 to bs=1m and rebuild g4u, or just try dd directly.
>
> (Why did I use 512 byte blocks? To skip forward to the right partition,
> and get size etc. right, as those numbers are stored in those units, at
> least in the BSD disk label, probably the MBR, too. I'm sure there's some
> ways better way, I just never got my brains together to do this right. Now
> guess why that's not really documented/enabled. :-)
>
>
> - Hubert
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
g4u-help mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/g4u-help
