Date: Fri, 9 Apr 2010 07:52:29 -0600 From: Scott Long <scottl@samsco.org> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: arch@freebsd.org, Andriy Gapon <avg@freebsd.org> Subject: Re: (in)appropriate uses for MAXBSIZE Message-ID: <07A7155D-0836-4D8C-BCF4-70FC16C77B69@samsco.org> In-Reply-To: <Pine.GSO.4.63.1004090941200.14439@muncher.cs.uoguelph.ca> References: <4BBEE2DD.3090409@freebsd.org> <Pine.GSO.4.63.1004090941200.14439@muncher.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?07A7155D-0836-4D8C-BCF4-70FC16C77B69>