Hi Sebastian,

read_pages is a small piece of code, please paste the complete
function with your changes over here, I am sure there must be some
minor bug otherwise page->lru.next looks fine to me.

I am wondering how the main loop of read_pages()

       for (page_idx = 0; page_idx < nr_pages; page_idx++) {
               struct page *page = list_to_page(pages);
               [..]
       }

really iterates, if neither the address of pages changes in the loop nor
page_idx is passed to anything.  I would think the loop is actually
accessing the same page again and again, but somehow my own

No its not iterating same page, you missed the call to
list_del(&page->lru) in the main loop. Remember it removes the first
element from the head of the list (as this page is now responsibility
of page cache) and next element automatically becomes head of the list
ie. list_head *pages.

I want to trace down all reads and writes to the file system including
filename, offset and byte count into a log that I can reply inside a
simulator.

for filename you have to track open calls to file system but remember
for resolving the complete path name, you have to get into depths of
namespace and play with vfsmount data structure.

Rajat

On Wed, Jan 12, 2011 at 12:46 AM, Sebastian Pipping
[off-list ref] wrote:

On 01/07/11 07:26, Rajat Sharma wrote:

quoted

so, suitable position is to add hooks on readpage a_op. And of-course
for doing that, you may have to capture various path thorugh which inode
can come in memory, e.g. lookup and create directory inode operation
(for regular files). For your worst nightmare, NFS implements its
readdir with an additional feature with v3 protocol called READDIR PLUS,
which not only gives you name of children of a directory, but also
initializes their inodes in memory, so you may have to hook readdir as
well and trap aops of all regular file child after nfs_readdir is

finished.

I see.

quoted

As far as offset and length of I/O are concerned, page->index gives you
its index in the page cache which in turn is equivalent to file offset
(page->index << PAGE_SHIFT). readpage is invoked to bring in complete
page in memory. It may so happen that page is a partial page (e.g. last
page of file), in that case your I/O lenght will be inode->i_size &
~PAGE_MASK, otherwise it can be PAGE_SIZE. don't worry about file
wholes, that is taken care by filesystem's original readpage method.

That sounds great. ?I have added these lines of code to read_pages() of
mm/readahead.c:

================================================
{
?struct page *page = list_to_page(pages);
?for (page_idx = 0; page_idx < nr_pages;
? ? ?page_idx++,
? ? ?page = list_to_page(page->lru.next)) {
? ?pgoff_t offset = 0;
? ?pgoff_t len = PAGE_SIZE;

? ?if (page) {
? ? ?offset = page->index << PAGE_SHIFT;

? ? ?if (page->mapping && page->mapping->host) {
? ? ? ?struct inode *inode = page->mapping->host;
? ? ? ?len = inode->i_size & ~PAGE_MASK;
? ? ?}
? ?}

? ?printk(KERN_DEBUG "VFS: BODY at 1 read_pages(...)["
? ? ? ?"page_idx=%u, offset=%lu, len=%lu, page_size=%lu]",
? ? ? ?page_idx, offset, len, PAGE_SIZE);
?}
}
================================================

Suprisingly I never get len != PAGE_SIZE, i.e. partial pages.
Also, in a list of pages given, the offsets are all the same, all 0 in
this case:

================================================
[ 2811.993564] VFS: BODY at 1 read_pages(...)[page_idx=0, offset=0,
len=4096, page_size=4096]
[ 2811.996456] VFS: BODY at 1 read_pages(...)[page_idx=1, offset=0,
len=4096, page_size=4096]
[ 2811.999305] VFS: BODY at 1 read_pages(...)[page_idx=2, offset=0,
len=4096, page_size=4096]
[ 2812.002152] VFS: BODY at 1 read_pages(...)[page_idx=3, offset=0,
len=4096, page_size=4096]
================================================

Is ?page = list_to_page(page->lru.next) ?the correct way of walking
pages? ?I am wondering how the main loop of read_pages()

? ? ? ?for (page_idx = 0; page_idx < nr_pages; page_idx++) {
? ? ? ? ? ? ? ?struct page *page = list_to_page(pages);
? ? ? ? ? ? ? ?[..]
? ? ? ?}

really iterates, if neither the address of pages changes in the loop nor
page_idx is passed to anything. ?I would think the loop is actually
accessing the same page again and again, but somehow my own

?page = list_to_page(page->lru.next)

above doesn't seem to do better. ?Any insights?

Thanks!

quoted

Having said above, it will still be better if you can state what you
want to achieve in little layman language.

I want to trace down all reads and writes to the file system including
filename, offset and byte count into a log that I can reply inside a
simulator.

Best,




Sebastian