Re: [RFC PATCH] Filesystem Journal Notifications

[Dave Chinner <david@fromorbit.com>]

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@fromorbit.com