From owner-cvs-all Wed Jan 9 9:14:44 2002 Delivered-To: cvs-all@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 953F437B41B; Wed, 9 Jan 2002 09:14:38 -0800 (PST) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 9 Jan 2002 17:14:37 +0000 (GMT) To: Mike Silbersack Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/boot/i386/boot2 boot2.c In-Reply-To: Your message of "Wed, 09 Jan 2002 10:24:24 GMT." <20020109102330.A2484-100000@patrocles.silby.com> Date: Wed, 09 Jan 2002 17:14:36 +0000 From: Ian Dowse Message-ID: <200201091714.aa02189@salmon.maths.tcd.ie> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20020109102330.A2484-100000@patrocles.silby.com>, Mike Silbersack w rites: > >Should we just be jumping right to 32K or 64K now? I believe that some >people already use such blocksizes on large filesystems. I posted a patch a day or two ago that makes the buffer size more dynamic in the i386 case, to avoid the need for a defined maximum block size. Mike Smith suggested just changing the limit to 16k for 4.5-RELEASE, and I agree that this is the safest thing to do for now. The boot environment is quite restricted, so I'm not sure offhand if we can safely go to 32k or 64k without further changes. In fact, a much better approach would be to change the code so that it reads large blocks in fixed-sized chunks. I'll see if that can be done without too much additional code-bloat. Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message