Re: [GSoC 2010][RESEND] Questions on Improved async/vector i/o support, fscache integration, and VFS change notification

On Mon, 5 Apr 2010 21:47:32 +0200
Mohammed Gamal <[email protected]> wrote:

> On Mon, Apr 5, 2010 at 1:16 PM, Jeff Layton <[email protected]> wrote:
> > On Sat, 3 Apr 2010 21:02:55 +0200
> > Mohammed Gamal <[email protected]> wrote:
> >
> >> On Sat, Apr 3, 2010 at 12:46 PM, Jeff Layton <[email protected]> wrote:
> >> > On Sat, 3 Apr 2010 12:16:34 +0200
> >> > Mohammed Gamal <[email protected]> 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.
> >
> 
> So in other words, the current event notification approach only works
> for local filesystems because the watches are seen by locally running
> copies of the kernel, but the events can't be delivered to objects
> that aren't locally stored, so we need the events to be delivered to
> the CIFS client through VFS so that it can send it across the network,
> am I getting the right picture?
> 

(Re-cc'ing those on the original thread)

Yes, that's more or less correct.

> > 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.
> >
> 
> I guess other network filesystems such as NFS and kAFS would benefit
> from the presence of such an interface if they too support change
> notification events, no?
> 

NFS doesn't support anything like that (to my knowledge), unless you
count delegation recalls. Not sure about AFS.

A VFS interface for this might have uses beyond network filesystems.
Clustered filesystems, for instance...

-- 
Jeff Layton <[email protected]>