From owner-freebsd-arch@FreeBSD.ORG  Fri Apr  9 13:52:32 2010
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: arch@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 75FEC1065673;
	Fri,  9 Apr 2010 13:52:32 +0000 (UTC)
	(envelope-from scottl@samsco.org)
Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57])
	by mx1.freebsd.org (Postfix) with ESMTP id 336C78FC34;
	Fri,  9 Apr 2010 13:52:31 +0000 (UTC)
Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57])
	(authenticated bits=0)
	by pooker.samsco.org (8.14.3/8.14.3) with ESMTP id o39DqTqY085704;
	Fri, 9 Apr 2010 07:52:29 -0600 (MDT)
	(envelope-from scottl@samsco.org)
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
From: Scott Long <scottl@samsco.org>
In-Reply-To: <Pine.GSO.4.63.1004090941200.14439@muncher.cs.uoguelph.ca>
Date: Fri, 9 Apr 2010 07:52:29 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <07A7155D-0836-4D8C-BCF4-70FC16C77B69@samsco.org>
References: <4BBEE2DD.3090409@freebsd.org>
	<Pine.GSO.4.63.1004090941200.14439@muncher.cs.uoguelph.ca>
To: Rick Macklem <rmacklem@uoguelph.ca>
X-Mailer: Apple Mail (2.1078)
X-Spam-Status: No, score=-1.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD
	autolearn=unavailable version=3.3.0
X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org
Cc: arch@freebsd.org, Andriy Gapon <avg@freebsd.org>
Subject: Re: (in)appropriate uses for MAXBSIZE
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Apr 2010 13:52:32 -0000

On Apr 9, 2010, at 7:53 AM, Rick Macklem wrote:
>=20
>> - What are appropriate and inappropriate uses for MAXBSIZE given the =
questions
>> above?  In other words, what would immediately break were we to =
simplemindedly
>> bump MAXBSIZE value.
>>=20
>> I have no answers but have some observations.
>> I strongly believe that all uses of MAXBSIZE in sys/dev/ are =
inappropriate.  For
>> me it's inconceivable that a hardware driver would need to know =
maximum size of
>> a filesystem block.
>=20
> I think you are on the right track here. It seems to me that MAXBSIZE
> (or some new constant instead of it) should define the maximum block
> size handled by the buffer cache. I have no idea what the implications
> of increasing it are, but it sounds like some drivers will need to be
> fixed, as you've noted.

Storage drivers are insulated from the details of MAXBSIZE by GEOM =
honoring
the driver's advertised max-i/o-size attribute.  What I see when I grep =
through the
sources are mostly uses in busdma attributes, which themselves probably =
came
via cut-n-paste from prior drivers.  I can't come up with any =
explanation for that
which makes good design sense, so I'll agree that storage drivers =
shouldn't
reference MAXBSIZE.

Scott