Re: How does NFS handle notify?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2011/5/2 Trond Myklebust <Trond.Myklebust@xxxxxxxxxx>:
>> Next via a daemon like Gamin. Yes, possible, but is this smart? Isn't
>> it just possible through the VFS like above described.
>
> All filesystems should already support notification for files that are
> created through the VFS.

Exact, only I like to say here that the filesystems do not have to do
anything for that.
The VFS combines various things here. The filesystem self does not do
anything here.

>
> The missing bit is to support notification for files that are created on
> the _server_ and that never go through the client VFS. That is precisely
> the problem that projects such as FAM and gamin are supposed to solve
> using generic userland daemons that can re-export the notifications from
> the NFS/CIFS/... server to any interested listeners.

Yes that's also true. If you are taking nfs, cifs or a FUSE fs, where
the server is for example the localhost self, thus more like backend.
I 'm not very convinced Gamin is the way to go.

Let me explain:

for example a simple overlay FUSE fs, fusexmp-bind.
It's behaving like a mount bind, making the contents of the directory
to bind available under the mountpoint.

Now user a mounts it like:

mkdir ~/mount
fusexmp-bind --bind-directory=/tmp ~/mount

This makes the directory /tmp available under ~/mount for user a.
As you say, when the user does:

touch ~/mount/testfile1

any client watching the ~/mount directory (through notify) will be
notfied of this change, while
fusexmp-bind does not support inotify at all. It the VFS which does all that.

Now if any other process is doing something in /tmp,
the same client watching ~/mount will not get notified, until a hard
refresh command is given.
The kernel (VFS) does not understand (and does not have to) that the
directories /tmp and
~/mount are related.

A sollution is that the VFS makes the filesystem (in this case thus
fusexmp-bind) aware of a client
watching directory ~/mount.

This filesystem "knows" as the only one what to do with it, namenly
set a inotify watch (with the same mask) on /tmp, read any events
there and forward them back to the original inotify watch (the one on
~/mount).

I'm suggesting here the use of VFS, making the filesystem aware of an
inotify watch.

But what about gamin?? Is is possible to make gamin take care of the
changes, like with the simple example of above. Well, possible, but
with extra configuration.
And this is only a simple example. With much more complicated setups,
where the files and directories a client "sees", which may depend on
the specific context of that connection, Gamin cannot be aware af that
all.

So my suggestion is to make everything go through the filesystem. As I
mentioned above, the VFS should make the filesystem aware of a notify
watch being added, the filesystem should take the right action (like
sending a SMB2 CHANGE_NOTIFY Request to the server and wait for
anything to come back from the server with cifs, or setting another
intofy watch on the backend with the simple FUSE fs above, and with
NFS doing something simular like cifs) and giving any received event
back to the VFS.

There is another advantage here, which for my fs is interesting.
"Knowing" that there is a watch set on a certain inode is interesting.
My fs handles various resources, like local harddrives, usb sticks,
cdroms but also SMB shares mounted with cifs, and especially with
removable resources, like USB sticks and cdroms, it's very usefull
that someone is watching it. This prevents it from unmounting it. But
this counts for my fs.
Ans also, it helps my fs to stay upto date. I say here helps, is not a
complete garantee.

So, what's your opinion?

Stef
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux