Re: fs block size and PAGE_CACHE_SIZE

[David Chow <davidchow@shaolinmicro.com>]

Phillip Lougher wrote:

> David Chow wrote:
>
>> Hi all,
>>  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.
>>
>
> Both zisofs and squashfs (http://squashfs.sourceforge.net) use larger 
> than 4K blocks.  In the case of squashfs, it can uses blocks up to 
> 32K. Both of these are compressed read-only filesystems.
>
>> 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.
>
>>
>
> Squashfs in the read_page routine pushes the extra pages  (i.e. 3 
> extra 4K pages in the case of a 16K block) into the page cache using 
> grab_page_nowait(), which returns a page with the appropriate mapping 
> to be filled and marked uptodate.  To avoid race conditions this 
> routine will not sleep if the page is already locked.

The case for sleep or no sleep only works on uni processor systems and 
non-preemptive kernel. Since the file system is suppose to work on smp 
systems which sleeping or not doesn't really helps. As you know, cases 
where simultaneous read to the same block really block my head.

>
> Using read_cache_page() is dangerous, because it sleeps if the page 
> you are trying to fill is already locked.  When writing squashfs I hit 
> the problem where read_page was being called almost simultaneously for 
> different pages which were in the same (32K) block.  The first 
> invocation read the 32K block and locked it, then tried to push the 
> pages into the page cache using read_cache_page().  However, 
> read_cache_page slept when it tried to push the page that the second 
> invocation had locked.  The second invocation itself was sleeping 
> holding that lock, whilst waiting for the overal 32K block lock .

Thanks for your pointers.

regards,
David Chow