On Fri, Sep 12, 2008 at 03:06:49PM -0700, Abhijit Paithankar wrote: > Hi, > > On journaling file systems, applications need to know when the meta-data > changes to files are written to disks in a manner which is persistent to > crashes and reboots. > > One way to do it is to fsync every few operations. However, fsync is > blocking and affects performance. > > The other (more efficient) way is to have the filesystem notify the > application when a transaction/change is written to disk. > > This patch implements such a notification mechanism based on inotify for > Ext3 and Ext4. And as such is un-implementable for other filesystems like XFS. e.g. the "journal cookie" is a 32 bit type. XFS uses a 64 bit type for transaction ID in the journal (the log sequence number). I am assuming the journal cookie in a userspace visible type, as the application is going to get these in events and have to compare them, right? Also, XFS doesn't assign the LSN until the transaction commits into the in-core log buffer as the LSN is (partially) a function of the physical offset into the log. Hence at the time we resolve what the cookie might be, we are so far away from the create/link/unlink/etc code that we cannot build an fsnotify function.... If you are going to provide a userspace interface for this, the cookie really needs to be independent of filesystem journalling implementation. Perhaps it should be a sequence number that is opaque to the filesystem that is assigned by inotify. The filesystem then needs to carry that sequence number with the transaction and returns the provided cookie to the inotify commit callback. This avoids encoding a dependency on a specific journaling model into the inotify interface.... That way, you can make well defined rules for doing comparisons on cookies. i.e. determine from a pair of cookies which one is older. Why? because... > Every time an application creates, renames, unlinks, etc a file or > directory, a journal_cookie is sent via the inotify mechanism. Ofcourse, > the application has to first register for such notifications on the > files/directories of interest. > > Once the transaction corresponding to that journal_cookie is committed > to the journal another notification is sent to the application > indicating that the change is now persistent. ... that's pretty inefficient. We have two inotify events now for every transaction and one of them has to be issued in journal I/O completion context. We can reduce this down to a single event with a simple polling interface to the filesystem to find out what the last committed cookie was. With a well defined cookie we can then determine how many of the outstanding events have been committed with a simple comparison. That will halve the amount of events, and allow batch processing which will be far more efficient that processing an event at a time. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
