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

[Alex Liu]

Hi, Steve,

On Fri, Apr 9, 2010 at 11:00 AM, Steve French <smfrench at gmail.com> wrote:
> 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)
Thanks for the hint. It really helps in designing the cifs inotify support.
>
> 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
I've looked at cifspdu.h and one of your slides. They give me a good
example to follow. Thank you!
>
> 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.
I think extending the existing SMB2 CHANGE_NOTIFY request would be
more straight and understandable. And I write my proposal that way.
Thanks for the info :)

Cheers,
-Alex