[patch] ramdisk blocksize Kconfig entry

[patch] ramdisk blocksize Kconfig entry

[Nathan Scott]

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

Signed-off-by: Nathan Scott <nathans@sgi.com>


Index: ramdisk-2.6/drivers/block/Kconfig
===================================================================
--- ramdisk-2.6.orig/drivers/block/Kconfig	2006-07-11 16:56:03.594339750 +1000
+++ ramdisk-2.6/drivers/block/Kconfig	2006-07-11 16:57:34.984051250 +1000
@@ -400,6 +400,16 @@ config BLK_DEV_RAM_SIZE
 	  what are you doing. If you are using IBM S/390, then set this to
 	  8192.
 
+config BLK_DEV_RAM_BLOCKSIZE
+	int "Default RAM disk block size (bytes)"
+	depends on BLK_DEV_RAM
+	default "1024"
+	help
+	  The default value is 1024 kilobytes.  PAGE_SIZE is a much more
+	  efficient choice however.  The default is kept to ensure initrd
+	  setups function - apparently needed by the rd_load_image routine
+	  that supposes the filesystem in the image uses a 1024 blocksize.
+
 config BLK_DEV_INITRD
 	bool "Initial RAM filesystem and RAM disk (initramfs/initrd) support"
 	depends on BROKEN || !FRV
Index: ramdisk-2.6/drivers/block/rd.c
===================================================================
--- ramdisk-2.6.orig/drivers/block/rd.c	2006-07-11 16:56:06.822541500 +1000
+++ ramdisk-2.6/drivers/block/rd.c	2006-07-11 16:56:47.065056500 +1000
@@ -84,7 +84,7 @@ int rd_size = CONFIG_BLK_DEV_RAM_SIZE;		
  * behaviour. The default is still BLOCK_SIZE (needed by rd_load_image that
  * supposes the filesystem in the image uses a BLOCK_SIZE blocksize).
  */
-static int rd_blocksize = BLOCK_SIZE;		/* blocksize of the RAM disks */
+static int rd_blocksize = CONFIG_BLK_DEV_RAM_BLOCKSIZE;
 
 /*
  * Copyright (C) 2000 Linus Torvalds.

Re: [patch] ramdisk blocksize Kconfig entry

[H. Peter Anvin]

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.

	-hpa

Re: [patch] ramdisk blocksize Kconfig entry

[Nathan Scott]

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