From: Al Viro <viro@ZenIV.linux.org.uk>
To: Stef Bon <stefbon@gmail.com>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: Again:request for integration inotify in FUSE and fs like CIFS.
Date: Sat, 19 Mar 2011 09:49:26 +0000 [thread overview]
Message-ID: <20110319094926.GN22723@ZenIV.linux.org.uk> (raw)
In-Reply-To: <AANLkTing8q=0Ny+fypPZn4OcV351gSJd4Urvzv0_ppEt@mail.gmail.com>
On Sat, Mar 19, 2011 at 09:56:17AM +0100, Stef Bon wrote:
> changes on the inode. When it recieves
> some data(inotify events), it will push them forward to the inotify
> watch on /home/a/mount/tmp. This is upto the developer
> of the FUSE fs to implement this, but required to make this work is:
>
> a. when there is a notify watch set on a mounted FUSE fs, the VFS
> should send the FUSE fs a signal a watch (with a mask) is set on a
> particular inode. (and also when it's removed)
>
> b. the VFS should be able to listen to notify events coming from the FUSE fs.
>
> Actually the VFS is signalling to the FUSE fs that it wants to have an
> inode to be up to date, and to be informed when changes occur.
>
> This example is about FUSE, but it also counts for a fs like cifs.
> There the backend is a SMB share, and the SMB server has to support
> inotify
> to make this work.
>
> I hope you get the picture,
Why, yes, we do. You do not. It is up to you to implement that; it is
up to us to decide whether the result is acceptable for merge...
FWIW, it's a bloody bad idea; inotify is not a generally usable mechanism.
There is no way to make it work for non-local filesystems. You might be
able to hack up something in FUSE protocol; getting FUSE *servers* to
honour that is something entirely different, seeing that there are tons
of them and these codebases are not in any way under control of kernel
developers - or any single group, for that matter. Then there is NFS,
where even the protocol side of things is not up to us, not to mention
the server implementations. The same goes for CIFS/SMB, only there the
odds of affecting the protocol (or one of the common servers - you know,
the native Windows one) are even slimmer.
Program relying on inotify is relying on specific configuration. Namely,
the areas of the mount tree it's going to watch belonging to one of the
filesystems where inotify works. Depending on what you are trying to do
there might be saner (and more robust) ways to go - hard to tell without
knowing what are you trying to achieve.
next prev parent reply other threads:[~2011-03-19 10:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-19 8:56 Again:request for integration inotify in FUSE and fs like CIFS Stef Bon
2011-03-19 9:49 ` Al Viro [this message]
2011-03-19 10:39 ` Stef Bon
2011-03-20 14:02 ` Jeff Layton
2011-03-20 15:55 ` Stef Bon
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=20110319094926.GN22723@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=linux-fsdevel@vger.kernel.org \
--cc=stefbon@gmail.com \
/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.