query regarding inode pages

[shubham sharma]

Hi Joel,

On Wed, Jul 13, 2011 at 9:28 PM, Joel A Fernandes <agnel.joel at gmail.com> wrote:
> [CC'ing list]
>
> Hi Shubham,
>
> I am not very familiar with the code for pdflush. But wasn't it
> superseded by bdflush (or similar) in recent kernels?

I don't know about the bdflush daemon, but I guess that pdflush daemon
has been superseded in recent kernel. I am working on 2.6.18 kernel.

>
> On Wed, Jul 13, 2011 at 10:45 AM, shubham sharma <shubham20006 at gmail.com> wrote:
>> I am trying to write a memory based file system. The file system is
>> intended to create files/directories and write their contents only on
>> pages. For this I have used the function grab_cache_page() function to
>> get a new locked page in case the page does not exists in the radix
>> tree of the inode.
>>
>> As the filesystem is memory based and all the data exists only on the
>> memory, so I don't release the lock on the page as I fear that the
>> pdflush daemon can swap out the pages on which I have written data and
>> I may never see that data again. I unlock all the pages of all the
>> inodes of the file system in the kill_sb function once the file system
>> is being unmounted. But the problem I am facing is that if I open a
>> file in which I have already written something (and its pages are
>> locked), the open system call in turn calls the __lock_page() function
>> which waits for the pages belonging to the inode to get unlocked.
>> Hence the system call stalls indefinitely. I want to know if there is
>> a mechanism by which I can prevent the pdflush daemon from swapping
>> the pages that my filesystem refers to??
>
> I'm not sure if pdflush is what "swaps" pages? Isn't that the role of
> kswapd? pdflush AFAIK just writes dirty pages back to the backing
> device.
>
> I think what you're referring to is a certain page replacement
> behavior in low memory conditions that you want to protect your
> filesystem against.

Yes you got it correct. I want to protect my filesystem against low
memory conditions.

>I will be interested in responses from others
> about this, and will dig into the code during off office hours.
>
> Maybe tmpfs is a good reference for your work?

Thanks for the lead. I will dig in that now.
>
> Thanks,
> Joel
>
Thanks,
Shubham