On Mon, 2007-02-26 at 14:35 +0200, Tzahi Fadida wrote: > On Monday 26 February 2007 14:08, Arjan van de Ven wrote: > > On Mon, 2007-02-26 at 14:01 +0200, Ramagudi Naziir wrote: > > > Hi Arjan, > > > > > > On 2/26/07, Arjan van de Ven <arjan@xxxxxxxxxxxxx> wrote: > > > > On Sat, 2007-02-24 at 20:33 +0000, Liran wrote: > > > > > I want to develop a kernel module that will be used to account for > > > > > the input/output of files on the system > > > > > and was wondering about doing it by intercepting the open() / read() > > > > > / write() system calls with their size attributes > > > > > and using that as a counter. (Later on, I wish to attach to a > > > > > specific pid or account for all i/o for a specific user but that's > > > > > later). > > > > > > > > I think your first misconception is that all IO starts with a > > > > syscall... that's actually very much not the case (hint: mmap'd areas). > > > > > > Can you please elaborate ? whare / what apps make use of mmap'd areas ? > > > > glibc can for stdio > > all databases do > > all database libraries tend to do this > > ... the list goes on. it can be everywhere > > 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). 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 -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
