On Monday 26 February 2007 15:57, Avishay Traeger wrote: > > So what do you suggest? in file $SRC/block/ll_rw_blk.c there is a > > function submit_bio. There lives the block_dump debugging construct. Does > > this function takes into account the mmaped areas? (i.e. does the dirty > > work for them). > > A couple problems: > 1. There is no clean way (as far as I know) to replace this function > with your own (assuming kprobes still isn't an option). However, you > may be able to write a device driver that will capture the information > for you, before passing it on to the real driver. I think this is > possible in Linux, but I'm not a driver guy. > 2. At this point in the processing of the request, you have lost a lot > of information. The original post was interested in tracking > open/read/write, as well as user ID, file name, etc. At this point, you > don't have any information about files or users. Furthermore, you can't > even tell the difference between open and read (both will really just be > reads from the block device). The original question from Liran was about the open read write syscalls, however, i am interested more in the I/O of a process so it suits my purposes. I am looking to see if there is a way to measure per process I/O like a TaskManager in windows does. Obviously, there are other problems with the submit_bio function that it does not measure dirtied buffers which i believe are being updated by a kupdated process. I.e., you will also have to change something in the kupdated process to tell you for which process he is doing the de-dirty buffering :). However, many times people are only interested in file interactions (or at least i thought so). But, the thing with the mmap, i think also falls in the kupdated territory so it can be a problem. > > I would suggest a stackable file system. This is a file system that > stacks on top of an existing file system. The stackable file system can > gather all the statistics you want that are passing through to the file > system that you are mounted on. It is a clean solution, and shouldn't > add much overhead. In addition, it will also catch all of the mmap > calls. > > There are templates for stackable file systems available here: > http://filesystems.org/project-fist.html > (The site also has links to several papers and articles so that you can > learn more). > > Avishay -- Regards, Tzahi. -- Tzahi Fadida Blog: http://tzahi.blogsite.org | Home Site: http://tzahi.webhop.info WARNING TO SPAMMERS: see at http://members.lycos.co.uk/my2nis/spamwarning.html -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
