Home / server / Questions / 23109
In Process
carlito
Asked: 2009-06-10 20:17:57 +0800 CST

Monitor, extend, and Index Linux filesystems

  • 772

I want to trap the below operations on a Linux system. Is it possible to do so efficiently? My end goal is to provide auditing and an additional set of filesystem metadata that is indexed differently. If the answer is "no", I appreciate pointers in a useful direction.


1) open(), and its parameters (where flags is O_CREAT)
2) write(), along with its parameters, *buf, and the struct file for fd, including f_pos
3) the corresponding information in 2 for a memory-mapped write to a file. I realize I'm asking something very difficult here as it requires an incestuous knowledge between the layers. Setting a flag that memory-mapped IO to a given open file has occurred is good enough, similar to how O_DIRECT writes might be handled. (triggering a later re-scan).
4) rename(), unlink()
5) mkdir(), rmdir()
6) truncate(), ftruncate()

If there are competing technologies to trap these kinds of operations, I am most interested in those that will last the longest (the most stability and community support), and those that are least filesystem-specific (the reiser4 plugins were exciting but don't seem politically viable).

Although my list 1-6 are simply examples, ideas as to what I've forgotten are helpful. But I'm not trying to be comprehensive, just communicate my design goal.

For example, passing this data to userspace would allow keeping a live locate/updatedb index. It would allow a database to track a per-block and per-file MD5. The availability of this data could facilitate snapshotting.

linux filesystems

5 Answers

  1. You want to use incrond. From the manpage:

       The inotify cron daemon (incrond) is a daemon which monitors filesystem
   events and executes commands defined in system and  user  tables.  It’s
   use is generally similar to cron(8).
    • 3

  2. Here are some related posts:

    I'd consider the first to be a nice snapshotting solution if LVM or the upcoming NILFS2 aren't what you are looking for. Of course NILFS2 isn't tested extensively you'll have to decide for yourself if you take the risk and put that on a production server.

    The second reference is more like security auditing but point roughly in the same direction.

    • 1

  3. How about SystemTap? It is like Dtrace on Solaris. At least for system calls it seems to be a nice solution. It seems well supported on Fedora.

    • 1

  4. Take a look at auditd. It should provide you with what you need.

    • 1

  5. SeLinux combined with auditd is a way to get that data using methods that are already in the kernel.

    Another option could be to use LD_PRELOAD tricks if you only want it for one application.

    • 1