inotify and nfsd exported filesystem
Subsystems (2)
i was only testing for IN_OPEN and IN_CLOSE_NOWRITE ( http://inotify-t=
ools.sourceforge.net/api/inotifytools_8h.html )
can do more in depth test tomorrow.
Quoted 8 lines
-----Urspr=FCngliche Nachricht-----
Von: "J. Bruce Fields" <[email protected]>
Gesendet: 22.01.08 21:29:42
An: devzero-S0/[email protected]
CC: [email protected]
Betreff: Re: inotify and nfsd exported filesystem
Quoted 5 lines
=20
Quoted 3 lines · On Tue, Jan 22, 2008 at 09:26:24PM +0100, devzero-S0/[email protected]…
hello !
=20
it seems that accessing a file via knfsd exported filesystem doesn`=
t
Quoted 9 lines
Quoted 2 lines
create an appropriate event with inotify-tools, i.e. i cannot "see" that this file has been accessed.
=20
What do you mean by "accessing"--is it just reads that are missed? Writes as well? Other kinds of modications of the filesystem? =20
--b.
=20Quoted 1 line
no problems if acess that file on the same machine via userspace - =
but
Quoted 6 lines
Quoted 5 lines
accessing from a remote box via nfs just fails.
=20
can somebody confirm this issue?
=20
is this by design or is this a bug?=20
_______________________________________________________________________=
__
In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern und gestalten= !=20
Nur 3,99 EUR/Monat! http://www.maildomain.web.de/?mc=3D021114
A message that is not in the archive (sent off-list or not yet received): 120349239-S0/[email protected]
Quoted 1 line · On Tue, Jan 22, 2008 at 09:36:57PM +0100, devzero-S0/[email protected]…
i was only testing for
IN_OPENandIN_CLOSE_NOWRITE( http://inotify=
-tools.sourceforge.net/api/inotifytools_8h.html )
Something like CLOSE_NOWRITE is not in general going to be reliable, because, for obvious performance reasons, the client doesn't necessaril= y
always tell the server every time an application opens or closes a file= =2E
Quoted 1 line
can do more in depth test tomorrow.
Thanks.
--b.
Quoted 15 lines
=20
=20Quoted 6 lines
-----Urspr=C3=BCngliche Nachricht-----
Von: "J. Bruce Fields" <[email protected]>
Gesendet: 22.01.08 21:29:42
An: devzero-S0/[email protected]
CC: [email protected]
Betreff: Re: inotify and nfsd exported filesystem=20
=20Quoted 5 lines
=20
Quoted 3 lines · On Tue, Jan 22, 2008 at 09:26:24PM +0100, devzero-S0/[email protected]…
hello !
=20
it seems that accessing a file via knfsd exported filesystem does=
n`t
Quoted 1 line
Quoted 1 line
Quoted 1 line
create an appropriate event with inotify-tools, i.e. i cannot "se=
e"
Quoted 8 lines
Quoted 8 lines
Quoted 1 line
that this file has been accessed.
=20
What do you mean by "accessing"--is it just reads that are missed? Writes as well? Other kinds of modications of the filesystem? =20
--b.
=20Quoted 1 line
no problems if acess that file on the same machine via userspace =
- but
Quoted 9 lines
Quoted 6 lines
Quoted 5 lines
accessing from a remote box via nfs just fails.
=20
can somebody confirm this issue?
=20
is this by design or is this a bug?=20
=20
=20
_____________________________________________________________________=
____
Quoted 1 line
In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern und gestalt=
en!=20
Quoted 2 lines
Nur 3,99 EUR/Monat! http://www.maildomain.web.de/?mc=3D021114
=20
Quoted 3 lines · On Tuesday January 22, devzero-S0/[email protected] wrote:
i was only testing for
IN_OPENandIN_CLOSE_NOWRITE( http://inotify-tools.sourceforge.net/api/inotifytools_8h.html )can do more in depth test tomorrow.
If you are watching for inotify events on the server, and performing accesses on some client, then I would expect you to get an IN_OPEN followed immediately by an IN_CLOSE_{NO,}WRITE each time the client sends a READ or WRITE request respectively.
So if the client just opens the file and then closes it, you would get no INOTIFY events.
If the client performs open/read/close repeatedly, subsequent reads would come from cache, so you would only get one IN_OPEN/IN_CLOSE_NOWRITE
pair.
If the client performs writes, you should get a more predictable stream of IN_OPEN/IN_CLOSE_WRITE pairs, though they could be delayed a bit.
You results will probably be different (and possible more like what you expect) if you use NFSv4.
NeilBrown
A message that is not in the archive (sent off-list or not yet received): 18326.24905.512220.221488-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org
Quoted 17 lines · Neil Brown
Quoted 3 lines · On Tuesday January 22, devzero-S0/[email protected] wrote:
i was only testing for
IN_OPENandIN_CLOSE_NOWRITE( http://inotify-tools.sourceforge.net/api/inotifytools_8h.html )can do more in depth test tomorrow.
If you are watching for inotify events on the server, and performing accesses on some client, then I would expect you to get an
IN_OPENfollowed immediately by an IN_CLOSE_{NO,}WRITE each time the client sends a READ or WRITE request respectively.So if the client just opens the file and then closes it, you would get no INOTIFY events.
If the client performs open/read/close repeatedly, subsequent reads would come from cache, so you would only get one IN_OPEN/IN_CLOSE_NOWRITE
pair.
Quoted 6 lines
If the client performs writes, you should get a more predictable stream of IN_OPEN/IN_CLOSE_WRITE pairs, though they could be delayed a bit.
You results will probably be different (and possible more like what you expect) if you use NFSv4.
Until delegations are granted, and then you'll start missing some of the client's opens again....
I'd expect inotify to notice changes to directories and (after some delay) to file data, but wouldn't count on more than that.
--b.