Why was it necessary to interlock the blocksize reported by a file system with the superblock with the page cache and the ll_rw_block() interface? I've gotten to the bottom of the bmap() problem with using a 1024/2048/4096 blocksize and the problem is related to the way the page cache asks for pages. NWFS will suballocate files < volume blocksize (4K,8K,16K,32K,64K). These suballocated file runs are not always block aligned which results in the page cache getting partial or scattered runs. The page cache always seems to assume that the blocks for a page will conform to the sb->s_blocksize value (which is ok), however, what's stilted about this model is that the underlying logic in ll_rw_block() will enforce buffer head reads to this blocksize value. My benchmarking shows best performance on Linux at 1024 blocksize settings (drivers seems optimized to this case). I have found that if I define sb->s_blocksize to a certain value, buffer heads get rejected if I attempt other values because set_blocksize() fails if the superblock value does not match. I can completely get around this problem by setting everything to a blocksize of 512, and using buffer heads set to this blocksize, however, this eats up more memory and creates more overhead in the ll_rw_block() code since it has to merge all these requests, plus there's the overhead of allocating tons of buffer heads for all the 512 blocks. It also increases (oink) the bmap() interative calling to map a file since smaller blocksizes result in more calls through the page cache interface. I guess what I am asking is why does there need to be a correlation beween page cache superblock size and an artificial enforement underneath in ll_rw_block() to force block I/O operations to be the same. One would think that ideally, I/O requests would allow variable length sector operations up to any size, and a config option to allow the page cache to bmap() sizes independently of I/O requests to the disks. I can get around what's there, but it's wasteful of memory and runs slower. This is probably a Linus issue. Please Advise, Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
