Michael Sternberg wrote: > > We have to write driver that intercept all I/O to disk and notifies > user-mode application with following data: block length and device > number. What is a proper way to implement it: to write a block driver > above disk layer or to implement a file system filter ? If we'll > implement a file system filter could we miss some direct I/O to the disk > ? What kind of I/O could we miss ?
Before you try to write middle layers, look at kprobe and systemtap and search on the linux-kernel mailing list, in former discussions about kprobe one chap wrote about a block device interceptor that uses kprobes to do something similar to what you want. The file system layer is probably not a good fit for your needs since it doesn't really bother with the writes themselves, the block device may coalesce reads/writes and the block device may do read-ahead of which the file system will have no knowledge of. An intermediary block device will do the job but won't really be transparent for applications unless you go for great lengths. You'll need to tell applications to use that block device and/or mount that block device instead of the real block device. kprobes will be completely transparent since you'll simply intercept all calls to the function that you want and be able to log the data in a way the user mode programs can see it. I recommend relayfs to transfer binary data to user-mode, based on my experience with kernel tracing printk is just too slow. Baruch ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
