Re: fs block size and PAGE_CACHE_SIZE

[David Chow <davidchow@shaolinmicro.com>]

>
>
>> So it is impossible to do under 2.4? Since all the design of VFS and 
>> page cache assumes the underlying fs uses a 4k page or something 
>> equivalent less to the size of a PAGE_CACHE_SIZE as the largest unit 
>> of a cache. If you read Phillip Lougher's mail which points to the 
>> squash fs (read-only), plus the problem of sleeping which really 
>> impossible to implement a read/write fs on smp systems (which I 
>> suppose to, and the current fs already supported). If it is 
>> impossible, I don't bother to think though.
>
>
> Hi,
>
> I think you slightly mis-understood my post. There is no problem doing 
> this with SMP or pre-emptive kernels.
>
> What I did say was to point out it was better to use 
> grab_page_nowait() rather than read_cache_page. The problem with 
> read_cache_page is not to with smp or pre-emptive kernels, it is to do 
> with the fact read_cache_page tries to grab the lock of the page it is 
> called to fill. If the page is already locked by another process, it 
> will sleep on the lock. Grab_page_nowait() doesn't wait if the page is 
> locked.
>
> Regards
>
> Phillip Lougher
>
Thanks for your clarifications. But what to do if one page is locked out 
of 4 (a 16k block)? It is easy when readpage() so that I just fill the 
reset 12k with up-to-date data. But for write, it is likely I need 
something to compress, right? If I simply grab the page data without 
considering the lock, corruption will likely to occur. I should sleep 
and wait for the page lock since it might be never unlocked for some 
mmapped and locked pages in different vmarea. Have you consider this at 
all? This is where it comes different with rw fs.

regards,
David Chow