From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 2 12:23:48 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 9D4771065777; Thu, 2 Sep 2010 12:23:48 +0000 (UTC) Date: Thu, 2 Sep 2010 12:23:48 +0000 From: Alexander Best To: Dag-Erling =?iso-8859-15?Q?Sm=F8rgrav?= Message-ID: <20100902122348.GA38047@freebsd.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8639tsl5q0.fsf@ds4.des.no> Cc: freebsd-hackers@freebsd.org Subject: Re: expand_number() for fetch'es -B and -S switches X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 12:23:48 -0000 On Thu Sep 2 10, Dag-Erling Smørgrav wrote: > Alexander Best 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