Re: fs block size and PAGE_CACHE_SIZE

[Phillip Lougher <phillip@lougher.demon.co.uk>]

David Chow wrote:

> Trond Myklebust wrote:
>
>>>>>>> " " == David Chow <davidchow@shaolinmicro.com> writes:
>>>>>>>           
>>>>>>
>>
>>     > How can you make sure there are no race conditions in
>>     > populating multiple page caches and making them up-to-date
>>     > afterwards? Since readpage only make sures you lock one page,
>>
>> Have a browse through mm/readahead.c (in particular read_pages() and
>> read_cache_pages()).
>> The page is is anonymous when it gets locked, and is only added to the
>> page cache) if there is no existing page. The lock is only released by
>> the filler.
>>
>>     > If readpages() is added for 2.5, it doesn't mean read page
>>     > don't have to implement readpage(), right?
>>
>> Right. You still have to implement readpage.
>>
> 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

>
> regards,
> David Chow
>
>>  
>>
>
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>