[linux-cifs-client] [GSOC] Questions about the project goal of VFS change notify support

[Alex Liu]

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?

Thank you.
-Alex
>
> 3) Make sure it is easy for applications to see updates to directories
> or files as needed for their requirements  (e.g. autorefreshing file
> listing windows when files are created remotely).
>
> On Thu, Apr 8, 2010 at 11:46 AM, Alex Liu <alexliu1943 at gmail.com> wrote:
>> Hi, jlayton and sfrench,
>>
>> As I looked more closely to the CIFS/SMB2 protocol, I realized that
>> the NT_TRANSACT_NOTIFY_CHANGE and SMB2 CHANGE_NOTIFY commands are
>> designed only for directory change notification[1][2]. There is no
>> (single) file change notification mechanism per protocol design.
>>
>> I am currently designing the cifs inotify support anyway. But I think
>> it will be way too complicated and go beyond the design of CIFS/SMB2
>> protocols. As a result, there would be a high possibility that the
>> part of code can never get merged. I'm not sure if supporting inotify
>> in CIFS is a good idea, given that CIFS/SMB2 protocols don't support
>> it from the beginning.
>>
>> jlayton said yesterday on IRC that the original purpose of the project
>> is to bring back what was ripped out by commit 6badd79b. Commit
>> 6badd79b is only about dnotify. So I'm wondering if removing inotify
>> support really matters. And if you could shed some light on the final
>> goals of the project, we students can have a better understanding of
>> what we are going to do.
>>
>> Thanks!
>>
>> refs:
>> [1] http://msdn.microsoft.com/en-us/library/ee441586%28v=PROT.10%29.aspx
>> [2] http://msdn.microsoft.com/en-us/library/cc246602%28v=PROT.13%29.aspx
>>
>> Cheers,
>> -Alex
>>
>
>
>
> --
> Thanks,
>
> Steve
>