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

[Alex Liu]

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 :)

Thanks,
-Alex

>
> Such a interface used to exist, but it was poorly implemented and Al Viro
> ripped it out. Truthfully, this is less a CIFS/SMB project and much
> more of a project to add this interface to the VFS. Once that's done,
> the CIFS part will be relatively easy.
>
> --
> Jeff Layton <jlayton at samba.org>
> _______________________________________________
> linux-cifs-client mailing list
> linux-cifs-client at lists.samba.org
> https://lists.samba.org/mailman/listinfo/linux-cifs-client