HellO!

Inside the kernel we have an array called read_ahead[MAJOR(dev)] - a
true
offended to human mind ;-).

Let us have a look on it in the 2.4.10-pre14 kernel.

This array was supposed as a way for a block device to specify the most
desirable size
of chunks to read in in advance during block operations. However let's
have a look at the places (other then initializations) where the values
it holds
*actually* are used.

Inside fs/hfs/file.c:

hfs_do_read(..... int reada)

	if (reada) {
		if (blocks < read_ahead[MAJOR(dev)] / (HFS_SECTOR_SIZE>>9)) {
			blocks = read_ahead[MAJOR(dev)] / (HFS_SECTOR_SIZE>>9);
		}
		if (block + blocks > size) {
			blocks = size - block;
		}
	}

Here the desired value already is provided by the reada parameter.  We
don't
need to read it at all there, we should use the reada value directly
instead.

So the only places where read_ahead is used are only the
following ioctrl handler implementations:

The generic one:

./drivers/block/blkpg.c:
		case BLKRAGET:
			if (!arg)
				return -EINVAL;
			return put_user(read_ahead[MAJOR(dev)], (long *) arg);

And two specific ones:
./drivers/s390/block/xpram.c:
	case BLKRAGET: /* return the readahead value, 0x1263 */
		if (!arg)  return -EINVAL;
		err = 0; /* verify_area_20(VERIFY_WRITE, (long *) arg, sizeof(long));
		          * if (err) return err;
                          */
		put_user(read_ahead[MAJOR(inode->i_rdev)], (long *)arg);

		return 0;

./drivers/md/lvm.c: 
	case BLKRAGET:
		/* get current read ahead setting */
		P_IOCTL("%s -- lvm_blk_ioctl -- BLKRAGET\n", lvm_name);
		if (put_user(lv_ptr->lv_read_ahead, (long *)arg))
			return -EFAULT;
		break;

Therefore we can see that the read_ahead array is de facto only maybe
used as a
BOGOUS advice value for the user space.  At all other places it get's
only used
as a "write only" variable. We could therefore kill the WHOLE ARRAY and
all the
initialization code for it inside block device drivers where it get's
set!  We
would just have to replace it inside the ioctl handlers by a constant or
a
more appriopriate value and fix the bug in hfs! In fact the tests for
the
attached patch show that even ORACLE 9.0.1 doesn't bother with it, so I
have just
removed it.

So we thankfully to the wonderfull work by Andera and Alexander we can
now
get rid of this crappy read_ahead array. 

Marvelous isn't it?!