Hi Joel, On Wed, Jul 13, 2011 at 9:28 PM, Joel A Fernandes <agnel.joel@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@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