Simon Kirby wrote:
>
> With tcpdump in another window, I can see that the readahead doesn'
> start prefetching until it's right near the end of the data it
> fetched last, rather than doing it in advance.
That's a big fat bug. And it wouldn't be astonishing if my
shiny new readahead does the same thing - I haven't analysed/tested
this scenario. Shall though.
Knowing zero about NFS, this:
if (!PageError(page) && NFS_SERVER(inode)->rsize >= PAGE_CACHE_SIZE) {
error = nfs_readpage_async(file, inode, page);
goto out;
}
error = nfs_readpage_sync(file, inode, page);
would seem to indicate that it's important to have 4k or 8k rsize and
wsize.
> ...
>
> > OK, it's doing 128k of readahead there, which is a bit gross for a floppy.
> > You can tune that down with `blockdev --setra N /dev/floppy'. The
>
> Ooh, is there something like this for NFS?
In 2.4, /proc/sys/vm/[min|max]_readahead should affect NFS, I think.
In 2.5, no knobs yet. NFS is using the default_backing_dev_info's
readahead setting, which isn't tunable. It needs to create its
own backing_dev_info (probably per mount?), make each inode's
inode.i_data.backing_dev_info point at that backing_dev_info
structure and export it to userspace in some manner. Guess I
should have told Trond that ;)
> > but `mke2fs /dev/fd0' oopses in 2.5.30. ho hum)
>
> Yes, floppy in 2.5 has been broken for a while...
>
Well it's oopsing in the code which tries to work out the
device geometry:
generic_unplug_device (data=0x0) at /usr/src/25/include/asm/spinlock.h:117
117 {
(gdb) bt
#0 generic_unplug_device (data=0x0) at /usr/src/25/include/asm/spinlock.h:117
#1 0xc020b57c in __floppy_read_block_0 (bdev=0xf62c4e00) at floppy.c:3896
#2 0xc020b5f6 in floppy_read_block_0 (dev={value = 512}) at floppy.c:3915
#3 0xc020b745 in floppy_revalidate (dev={value = 512}) at floppy.c:3954
#4 0xc01448b7 in check_disk_change (bdev=0xf62c4e00) at block_dev.c:522
#5 0xc020b377 in floppy_open (inode=0xf54e5ec0, filp=0xf4baa1a0) at floppy.c:3808
#6 0xc0144bc6 in do_open (bdev=0xf62c4e00, inode=0xf54e5ec0, file=0xf4baa1a0) at block_dev.c:623
#7 0xc0144f63 in blkdev_open (inode=0xf54e5ec0, filp=0xf4baa1a0) at block_dev.c:740
#8 0xc013d83e in dentry_open (dentry=0xf62dc5e0, mnt=0xc3ff5ee0, flags=32768) at open.c:655
#9 0xc013d770 in filp_open (filename=0xf6362000 "/dev/fd0", flags=32768, mode=0) at open.c:624
#10 0xc013db4f in sys_open (filename=0xbffffb9c "/dev/fd0", flags=32768, mode=0) at open.c:800
#11 0xc0107123 in syscall_call () at stats.c:204
So if you use something with known geometry, like /dev/fd0h1440, it works!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 15 2002 - 22:00:24 EST