(in)appropriate uses for MAXBSIZE

Rick Macklem rmacklem at uoguelph.ca
Fri Apr 9 13:39:24 UTC 2010

On Fri, 9 Apr 2010, Andriy Gapon wrote:

> Nowadays several questions could be asked about MAXBSIZE.
> - Will we have to consider increasing MAXBSIZE?  Provided ever increasing media
> sizes, typical filesystem sizes, typical file sizes (all that multimedia) and
> even media sector sizes.

I would certainly like to see a larger MAXBSIZE for NFS. Solaris10 
currently uses 128K as a default I/O size and allows up to 1Mb. Using
larger I/O sizes for NFS is a simpler way to increase bulk data transfer
rate than more buffers and more agressive read-ahead/write-behind.

I had assumed that MAXBSIZE is the largest sized block handled by the
buffer cache? I have no idea what effect just increasing it has, but
had planned on experimenting with it someday.

> - Do we need a universal limit on block size for all filesystems?  E.g. ZFS
> already has maximum block size greater than MAXBSIZE, but it lives (has to
> live?) in a somewhat parallel world to other filesystems.

It's always going to be a tradeoff between using a generic buffer cache
mechanism shared between multiple file systems vs one specifically
designed for a given file system. (There are times when the generic
buffer cache is far from ideal for the NFS client, but I haven't
felt that the issues were serious enough to warrant building one
specifically for NFS.

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

Just my $0.00 worth, rick

More information about the freebsd-arch mailing list