From: Andreas Dilger <adilger@sun.com>
To: Abhijit Paithankar <apaithan@akamai.com>
Cc: linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
Jamie Lokier <jamie@shareable.org>,
Dave Chinner <david@fromorbit.com>,
Joel Becker <joel.becker@oracle.com>
Subject: Re: [RFC PATCH] Filesystem Journal Notifications
Date: Fri, 19 Sep 2008 14:34:03 -0600 [thread overview]
Message-ID: <20080919203402.GI10950@webber.adilger.int> (raw)
In-Reply-To: <20080916230552.GB13446@apaithan-desktop.sanmateo.corp.akamai.com>
On Sep 16, 2008 16:05 -0700, Abhijit Paithankar wrote:
> > Is there a reason NOT to use the journal commit callback mechanism that
> > I posted? This would only require registering a single callback for
> > each transaction for the inotify, but has the benefit of being completely
> > generic and can be used for other commit notifiers in the future.
>
> In the current patch if two applications want to be notified on the journal
> commit event they could register for IN_JOURNAL_COMMIT on the same inode,
> which could be the root inode of the file system.
>
> There is no limit on the number of applications that could register on the
> root inode for journal commit notifications. The only limitation is that
> they all have to register on the same inode for that partition.
>
> Any number of applications can register for the journal event as long as they
> register on the same inode.
That assumes agreement between the applications that are using this
interface. It isn't at all desirable that applications have to know
the "mountpoint" of the filesystem in order to use inotify, and in
some cases (e.g. bind mount in a new namespace) there isn't even access
to the root inode.
> The journal commit callback mechanism could be viable way to notify
> journal commits. However it is not clear to me how an application would
> register the callback.
The application registers for the callback via the inotify interface,
which in turn needs to have an interface to the filesystem to use the
fs-specific transaction commit callback.
> It is not clear to me how using journal_callback_set API would change
> that if we use inotify to register callbacks.
The journal_callback_set() API doesn't need to change at all (though in
fact Joel Becker of OCFS2 is implementing a more generic API that can be
used for other kinds of commit callbacks. He will hopefully post it to
this list soon.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
next prev parent reply other threads:[~2008-09-19 20:34 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-12 22:06 [RFC PATCH] Filesystem Journal Notifications Abhijit Paithankar
2008-09-13 9:19 ` Dave Chinner
2008-09-15 2:31 ` Andreas Dilger
2008-09-15 5:39 ` Andreas Dilger
2008-09-15 19:36 ` Abhijit Paithankar
2008-09-15 23:37 ` Andreas Dilger
2008-09-16 23:05 ` Abhijit Paithankar
2008-09-19 20:34 ` Andreas Dilger [this message]
2008-09-20 15:51 ` Jamie Lokier
2008-09-20 5:15 ` Jan Kara
2008-09-23 22:26 ` Andreas Dilger
2008-09-15 13:23 ` Jamie Lokier
2008-09-17 0:06 ` Abhijit Paithankar
2008-09-17 11:35 ` Jamie Lokier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080919203402.GI10950@webber.adilger.int \
--to=adilger@sun.com \
--cc=apaithan@akamai.com \
--cc=david@fromorbit.com \
--cc=jamie@shareable.org \
--cc=joel.becker@oracle.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).