Hi Joel, On Wed, Jul 13, 2011 at 9:28 PM, Joel A Fernandes <agnel.joel@xxxxxxxxx> 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@xxxxxxxxx> 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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
