Date: Thu, 2 Sep 2010 12:23:48 +0000 From: Alexander Best <arundel@freebsd.org> To: Dag-Erling =?iso-8859-15?Q?Sm=F8rgrav?= <des@des.no> Cc: freebsd-hackers@freebsd.org Subject: Re: expand_number() for fetch'es -B and -S switches Message-ID: <20100902122348.GA38047@freebsd.org> In-Reply-To: <8639tsl5q0.fsf@ds4.des.no> References: <20100831180103.GA92584@freebsd.org> <86fwxt5ng1.fsf@ds4.des.no> <20100901222834.GA66517@freebsd.org> <864oe8mpga.fsf@ds4.des.no> <20100902114655.GA9071@freebsd.org> <8639tsl5q0.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu Sep 2 10, Dag-Erling Smørgrav wrote: > Alexander Best <arundel@freebsd.org> writes: > > so how about something like this? the fetch(1) manual would have to be changed > > a bit to state that if '-B val' > 1G it silently gets set to 1G. > > 1 GB is ridiculously large. 1 MB should be plenty. the current maximum buffer limit of fetch(1) actually is around 1G. i think 1M is not enough, because if people are pulling data over fast lines they'll have almost constant disk writes. how about 100M then? ;) on the other hand why have a maximum limit? if people want to have a buffer of 100 gigabyte why shouldn't they? it's their decision actually. so maybe the maximum buffer check should just be left out and the only limitation will be that expand_number() can't handle anything that won't fit into uint64_t. cheers. alex > > DES > -- > Dag-Erling Smørgrav - des@des.no -- a13x
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100902122348.GA38047>