Re: [patch] ramdisk blocksize Kconfig entry

[Nathan Scott <nathans@sgi.com>]

On Tue, Jul 11, 2006 at 02:19:58PM -0700, H. Peter Anvin wrote:
> Nathan Scott wrote:
> > This patch makes the ramdisk blocksize configurable at kernel
> > compilation time rather than only at boot or module load time,
> > like a couple of the other ramdisk options.  I found this handy
> > awhile back but thought little of it, until recently asked by a
> > few of the testing folks here to be able to do the same thing
> > for their automated test setups.
> > 
> > The Kconfig comment is largely lifted from comments in rd.c,
> > and hopefully this will increase the chances of making folks
> > aware that the default value often isn't a great choice here
> > (for increasing values of PAGE_SIZE, even moreso).
> 
> This seems a bit odd to me... the sizes of most block devices is set by 
> the filesystem, not hard-coded; the need for this implies something more 
> fundamental is wrong.

The ramdisk driver is using this "blocksize" as what, in some other areas
of the block layer (and in XFS, but thats irrelevent here), is termed the
hard sector size - i.e. minimum IO size allowed to the device.  This gets
used for direct I/O size and alignment checking at the device level (the
block size of the filesystem sitting above the ramdisk has to be equal to
or greater than the device sector size).

The driver also uses this value for i_blkbits on individual block device
inodes (in rd_open), which in turn means buffer_heads attached to the
page cache pages which form the backing store for this device are sized
based on this, which potentially means many buffer_heads to a page. This
may not be what someone using it might have expected/wanted.

But I don't think these things are fundamental problems in the ramdisk
driver, rather design choices, and people using it should be aware of
the tradeoffs... what were you thinking of there in terms of something
more fundamental being wrong?

cheers.

-- 
Nathan