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

Hi, Layton,

On Mon, Apr 5, 2010 at 9:49 PM, Jeff Layton <[email protected]> wrote:
> On Mon, 5 Apr 2010 21:22:11 +0800
> Alex Liu <[email protected]> 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 <[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.
>> 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 :)
Thanks for your quick response.
I'd like to take challenges. I'll design the VFS hooks as soon as I
can and come back later if I have more questions.

Best,
-Alex
>
> --
> Jeff Layton <[email protected]>
>