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: > >> - 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. >> >> 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. > > 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>