Weblog

Thursday May 12, 2005

FEM: What and Why? I'm back already with my second entry. FEM, or File Event Monitoring, is a formalized mechanism to monitor events on a vnode or vfs by intercepting the vnode/vfs operations. The framework enables the consumer to request event notification for specified files and directories. The consumers, which intercepts the events, are responsible for delivering the event to the next intercepter or the terminal destination. Monitors so placed, inline, have the greatest flexibility as they are able to affect the control flow both before and after the event is delivered. In simple terms, it is a way to intercept vnode/vfs operations. It is only a framework and provides no real monitoring or notification. The monitor, which the consumer is responsible for writing, does all the work. FEM simply give you the ability to install a monitor on the operations you're interested in. I may write a "FEM: How?" entry which will go into the details of how it works and how to use it. The questions you should be asking now is why. Why did I putback a project that had a goal of having no overhead when it isn't used? And why isn't there a user API to use it? And why do we need a vnode/vfs intercept framework at all? All good questions and I'll partially answer them by explaining where it is currently being used. The project that wanted this, or at least file event notifications, was NFSv4. In version 4 of the NFS protocol, file delegation was introduced. Others have/will blog about delegation, so I won't get into details here. Anyway, the NFS server can grant file delegations to its clients, which allows the clients to feel safe using that file without others having conflicting access. When a conflicting access does occur, the server will recall the delegation. Now, if Sun servers were only accessed by NFS clients, there wouldn't have been a need for FEM. However, because we allow local access to the files, the NFS server needed to be notified when that happens. Hence the need for FEM. When the server grants a delegation, it installs a monitor on the vnode of the file it delegated. Then all open, read, write, setattr, rwlock, setsecattr, remove, rename operations are monitored for conflicts. If the monitor detects a conflict, it kicks off a recall and makes the operation wait for the delegation to be returned. When the delegation is returned (or revoked, if necessary), the monitor lets the operation that caused the conflict to continue. So there you have it. An introduction to FEM. I realize there is so much more to write about it, and I will. My next entry will include the kernel interfaces to FEM and an example of the monitor used by the NFS server. Hasta pronto. ( May 12 2005, 09:30:30 AM PDT ) Permalink Comments [2]