fs block size and PAGE_CACHE_SIZE

[David Chow <davidchow@shaolinmicro.com>]

Hi all,

I've got a question regarding filesystem block size (the arbitary internal fs block size) between the system's PAGE_CACHE_SIZE . Since the most common block size of fs in Linux is 4k, it is because it provides easy implementation of fs which directly matches the PAGE_CACHE_SIZE . As you know, new CPUs such as IA-64's can have a page size of 16k and above, I am wondering is it possible to implement an fs that has 16k block size on a 4k system which this fs can be used both on IA-32 and IA-64 systems. In other words, is it possible (or someone already done) to implement a file system that has 16k block size on a 4k paging system. Firstly, I think of working on a readpage() aop on a non aligned page no (in the middle of a block), how could I efficient populate one 16k block to page cache(4 pages) at one readpage() op? Since the fs driver could not really create a mapped page or telling whether a page (page no) is in the page cache or not. From my knowledge, one way of doing this
  is to use the read_cache_page() callback to tell whether the page is in page cache by knowing wether the callback is triggered. If I simply call read_cache_page() to aligned page in readpage() aop of unaligned pages, even the aligned page is up_to_date afterwards, how would it possible for the readpage() process to return an up_to_date page (guaranteed) for unaligned pages? I thought of locking the page, but the problem is that readpage() is called with the page locked, and call read_cache_page() on a cached aligned page will not trigger an fs read (page cache hit of aligned page doesn't mean an up_to_date for unaligned page). Since my fs implementation would be very inefficient if doing a reading in the middle of a block (compression file systems) or the overhead of reading will be 4 times higher on small page cache size systems. I am pleased to hear any suggestions on such implementations. Thanks.

regards,
David Chow