query regarding inode pages

[Joel A Fernandes]

[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?

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. 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,
Joel