On Mon, May 22, 2000 at 08:25:05AM -0400, Theodore Y. Ts'o wrote:
> This was discussed on IRC, but for those who weren't there ---- it
> should be clear that the current implementation uses dentries, so if you
> have a file which is hard-linked to appear in two different directories,
> only the parent directory which was used as an access path when the file
> was changed would get notified.
*nod*. I don't see this as too big a problem. Hard links are relatively
uncommon; particularly in the context where we immediately plan to use this.
> A much more obvious place where directory notification won't work is for
> any kind of shared filesystem --- i.e., GFS, or any other networked
> filesystem (NFS, smbfs, etc.). But that's for pretty obvious
> reasons....
Not necessarily. SMB has the NT_TRANSACT_NOTIFY_CHANGE call which
SMB could implement. I haven't done this as part of my patch; but the
i_op->fasync entry is per-filesystem, and SMB could have its own special
one to invoke this call. I thought about this carefully and decided to
put the default one in the network filesystems anyway as they can still
receive notifications whenever something changes locally.
> This is not to say that willy's work is bad, but people should
> understand where it works and where (and why) it won't work.
one of the things which concerns me most is that we throw away much of the
information about what changed because there isn't enough defined space
in the signal structure. There's plenty of space available (there's
something like 116 bytes unused). It'd be nice to say _which_ event
caused the notification. I suspect there would be some resistance to
defining a new field in the SIGPOLL arm of the union at this point though.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 23 2000 - 21:00:23 EST