From: NeilBrown <neilb@suse.de>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Jamie Lokier <jamie@shareable.org>,
Al Viro <viro@ZenIV.linux.org.uk>,
Sylvain Rochet <gradator@gradator.net>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-nfs@vger.kernel.org
Subject: Re: PROBLEM: 2.6.35.7 to 3.0 Inotify events missing
Date: Tue, 23 Aug 2011 09:21:50 +1000 [thread overview]
Message-ID: <20110823092150.366d8899@notabene.brown> (raw)
In-Reply-To: <20110822172239.GA15960@fieldses.org>
On Mon, 22 Aug 2011 13:22:39 -0400 "J. Bruce Fields" <bfields@fieldses.org>
wrote:
> On Mon, Aug 22, 2011 at 09:07:51AM +1000, NeilBrown wrote:
> > One is to use bind mounts. i.e. I effectively do
> > mount --bind $HOME/.config $HOME/.config
> > and ask for events from the newly created vfsmnt.
> > This will not catch changes made through file descriptors that were opened
> > before I did the mount, or through hard links from some other directory
> > tree. But for a particular use-case that might not be a problem.
>
> I'm missing what the extra vfsmount gets you here. The problems seem
> just the same as if you don't have one.
>
> Oh, wait, I see, it's that the file descriptors are associated with
> vfsmounts, not just dentries. Hm.
"Hm" might be right. writes have a 'struct file', but mkdir and rename etc
just get an inode.
So to be able to notify based on vfsmnt, mkdirat - for examine - would need
to pass the path to vfs_mkdir rather than path.dentry->d_inode, and vfs_mkdir
would have to pass that path to fsnotify_mkdir. So more intrusive that I
imagined, but still quite do-able.... if it were thought to be useful.
NeilBrown
WARNING: multiple messages have this Message-ID (diff)
From: NeilBrown <neilb-l3A5Bk7waGM@public.gmane.org>
To: "J. Bruce Fields" <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
Cc: Jamie Lokier <jamie-yetKDKU6eevNLxjTenLetw@public.gmane.org>,
Al Viro <viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
Sylvain Rochet <gradator-XWGZPxRNpGHk1uMJSBkQmQ@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: PROBLEM: 2.6.35.7 to 3.0 Inotify events missing
Date: Tue, 23 Aug 2011 09:21:50 +1000 [thread overview]
Message-ID: <20110823092150.366d8899@notabene.brown> (raw)
In-Reply-To: <20110822172239.GA15960-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
On Mon, 22 Aug 2011 13:22:39 -0400 "J. Bruce Fields" <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
wrote:
> On Mon, Aug 22, 2011 at 09:07:51AM +1000, NeilBrown wrote:
> > One is to use bind mounts. i.e. I effectively do
> > mount --bind $HOME/.config $HOME/.config
> > and ask for events from the newly created vfsmnt.
> > This will not catch changes made through file descriptors that were opened
> > before I did the mount, or through hard links from some other directory
> > tree. But for a particular use-case that might not be a problem.
>
> I'm missing what the extra vfsmount gets you here. The problems seem
> just the same as if you don't have one.
>
> Oh, wait, I see, it's that the file descriptors are associated with
> vfsmounts, not just dentries. Hm.
"Hm" might be right. writes have a 'struct file', but mkdir and rename etc
just get an inode.
So to be able to notify based on vfsmnt, mkdirat - for examine - would need
to pass the path to vfs_mkdir rather than path.dentry->d_inode, and vfs_mkdir
would have to pass that path to fsnotify_mkdir. So more intrusive that I
imagined, but still quite do-able.... if it were thought to be useful.
NeilBrown
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-08-22 23:22 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-18 22:35 PROBLEM: 2.6.35.7 Inotify events missing Sylvain Rochet
2011-08-19 23:03 ` PROBLEM: 2.6.35.7 to 3.0 " Sylvain Rochet
2011-08-19 23:37 ` Jamie Lokier
2011-08-19 23:37 ` Jamie Lokier
2011-08-20 0:47 ` Sylvain Rochet
2011-08-20 0:47 ` Sylvain Rochet
2011-08-20 3:21 ` Jamie Lokier
2011-08-20 1:29 ` Al Viro
2011-08-20 1:43 ` Randy Dunlap
2011-08-20 2:01 ` Al Viro
2011-08-20 3:03 ` Jamie Lokier
2011-08-20 3:03 ` Jamie Lokier
2011-08-21 17:07 ` J. Bruce Fields
2011-08-21 17:07 ` J. Bruce Fields
2011-08-21 20:20 ` Jamie Lokier
2011-08-21 20:20 ` Jamie Lokier
2011-08-21 23:07 ` NeilBrown
2011-08-22 17:22 ` J. Bruce Fields
2011-08-22 23:21 ` NeilBrown [this message]
2011-08-22 23:21 ` NeilBrown
2011-08-25 21:47 ` Sylvain Rochet
2011-08-21 22:29 ` NeilBrown
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=20110823092150.366d8899@notabene.brown \
--to=neilb@suse.de \
--cc=bfields@fieldses.org \
--cc=gradator@gradator.net \
--cc=jamie@shareable.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=viro@ZenIV.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.