[GSOC] Questions about the project goal of VFS change notify support

[Steve French]

On Thu, Apr 8, 2010 at 8:52 PM, Alex Liu <alexliu1943 at gmail.com> wrote:
> Hi, Steve,
>
> On Fri, Apr 9, 2010 at 1:18 AM, Steve French <smfrench at gmail.com> wrote:
>> I see three complementary goals for this kind of work:
>>
>> 1) Get as many apps as possible to work over network mounts:  fully
>> support the Linux fs entry points exposed from the vfs interface from
>> cifs (and smb2) clients, including as many of the optional ones as is
>> reasonably possible.  In the case of inotify and dnotify, we want to
>> support as many cases as possible with the cifs and smb2 protocols
>> (which may be slightly different for the two due to smb2 improvements
>> in the protocol design, and may require compensations on the client
>> side)
>>
>> 2) Expand the smb2 protocol with additional "posix extensions"
>> (unix/linux extensions) when holes are found in what the Linux vfs
>> asks us to support, but the smb2 wire protocol does not have a flag or
>> command for.   We want to keep these as small as reasonably possible,
>> but this (file/directory change notification is one area where it
>> could make sense
> Thanks for explaining this. If we can extend the smb2 protocol, life
> will be much easier.
> But again, I don't think there is any "posix extensions"(unix/linux
> extensions) that we can follow (NFS protocol doesn't have this kind of
> notification either). Do you think we can design the interface on our
> own? If so, there  may be no server support until we get the extension
> standardized.
> Is there a real world example that we extend the CIFS/SMB2 protocol in
> linux cifs client?

It may turn out we can simply use the existing SMB2 CHANGE_NOTIFY
request but pass it a fileid that really is for an open file (rather than an
open directory handle), but there could be other changes (e.g
how to show that the server supports such operations on files perhaps
on tcons as we did via a QueryFS info level)

The cifs protocol was extended multiple times for unix/linux as various
client implementers found holes while developing smb/cifs clients
for the various unix, unix-like and linux.  We sometimes
called later versions of this "posix extensions" (cifspdu.h shows some of
the optional capability flags, and there are some presentations on these
extensions which I have done at various conferences) so could
be used as a model

For SMB2 there is an interesting way to add extensions that
some of the Apple guys suggested would help make some of the
Unix/Linux extensions easier (although not certain if it would
help for inotify).   SMB2 allows adding optional "create contexts"
to the SMB2 Create (open) request and/or response.




-- 
Thanks,

Steve