[linux-cifs-client] [GSoC 2010][RESEND] Questions on Improved async/vector i/o support, fscache integration, and VFS change notification

[Jeff Layton]

On Mon, 5 Apr 2010 21:22:11 +0800
Alex Liu <alexliu1943 at gmail.com> wrote:

> Hi, Layton,
> 
> My name is Alex Liu, and I'm a student from China. I just joined the
> linux-cifs-client mailing list and I'm also interested in the vfs
> change notify project. Please see my question below.
> 
> On Mon, Apr 5, 2010 at 7:16 PM, Jeff Layton <jlayton at samba.org> wrote:
> >
> > On Sat, 3 Apr 2010 21:02:55 +0200
> > Mohammed Gamal <m.gamal005 at gmail.com> wrote:
> >
> > > On Sat, Apr 3, 2010 at 12:46 PM, Jeff Layton <jlayton at samba.org> wrote:
> > > > On Sat, 3 Apr 2010 12:16:34 +0200
> > > > Mohammed Gamal <m.gamal005 at gmail.com> wrote:
> > > ... <snip> ...
> > >
> > > >> - VFS change notification: My understanding on a very high level is
> > > >> that a mechanism is needed for the smb server to respond to
> > > >> inotfiy/dnotify calls, push these calls to the clients who have the
> > > >> corresponding shares mounted, and then reflect these changes on their
> > > >> ends. Is that understanding correct? And which operations need to be
> > > >> done in kernel space? Which other need to be done in userspace? And
> > > >> what are the boundaries between the two?
> > > >>
> > > >
> > > > The CIFS/SMB protocol already supports asynchronous notification when a
> > > > file changes on the server (maybe directory too? not sure). This
> > > > project is about hooking CIFS up to this. The problem currently is that
> > > > the VFS doesn't call down into the lower filesystem when a program
> > > > wants to be notified of changes.
> > > >
> > > > So that would have to be added at the VFS layer first, and then CIFS
> > > > would have to turn that into a call to set up notifications on the
> > > > server. You'd also have to have CIFS do a fanotify event when a file on
> > > > the server changes. This is all kernel-space stuff.
> > > >
> > >
> > > Since inotify/dnotify calls are not delivered through the VFS then how
> > > do do notifications get delivered to userland? and which component
> > > delivers notifications to it if it's not the VFS or the lower
> > > filesystem?
> > >
> >
> > No, I think you misunderstand. In order for a program to receive
> > inotify/dnotify events, it has to tell the kernel what it wants to
> > monitor (via inotify_add_watch, for instance). The problem is that the
> > kernel doesn't pass that info down to CIFS. So you'd have to add an
> > interface into the VFS to do that.
> I've looked at fsnotify and we might be able to do this by patching
> fsnotify to send watchers down to the underlying fs. Once cifs client
> receives a change notify from the server, we can call hooks in
> fsnotify.h to reflect changes. An advantage of patching fsnotify is
> that we don't need to differentiate inotify and dnotify. But this is
> more of an issue in the vfs layer. Should we consult vfs developpers
> (such as Al Viro) and ask for their opinions before drawing our high
> level design? And maybe a new config option CONFIG_NFS_NOTIFY is
> needed to minimize the code impact, is it?
> 
> BTW, I've looked at the CIFS protocol and verified that the
> NT_TRANSACT_NOTIFY_CHANGE notification can be used to implement both
> inotify and dnotify. So we don't need to worry about the backend
> support :)
> 

Yes, inotify/dnotify are mostly different interfaces to the same kernel
fsnotify/fanotify subsystem. You're also quite correct that this is
really more of a generic VFS project. Once the VFS hooks are in place,
the part to make CIFS use it will be fairly easy.

You'll definitely want to consult with the generic fs devel folks. It's
usually easier to get a response on the development lists though if you
have working code to discuss. So you'll probably need to do something
like this:

1) design it as best you can
2) hack up a patchset for the VFS, plus maybe some stub filesystem code to prove that it works
3) post it to linux-fsdevel, LKML, etc...
4) collect feedback and review, fix the patchset based on that feedback
5) goto step 3 until you have something acceptable...

...it'll be an iterative process and will probably take quite a few
attempts to get it right. Because of that, this is probably one of the
more difficult projects listed on the SoC ideas page :)

-- 
Jeff Layton <jlayton at samba.org>