On Tue, Aug 21, 2012 at 04:22:31PM +0400, Pavel Emelyanov wrote:

On 08/21/2012 04:11 PM, J. Bruce Fields wrote:

quoted

On Tue, Aug 21, 2012 at 03:09:05PM +0400, Pavel Emelyanov wrote:

quoted

On 08/21/2012 02:54 PM, Cyrill Gorcunov wrote:

quoted

On Tue, Aug 21, 2012 at 02:49:47PM +0400, Pavel Emelyanov wrote:

quoted

quoted

quoted

However, if you have some better ideas on what information about inode should be exported
to the userspace please share.

Why not use name_to_handle(fd,...) and open_by_handle(handle,..) ?

Because we don't have an fd at hands by the time we need to know the handle.

Yeah, this might be not clear from patchset itself but inotify marks carry
inodes inside kernel thus it's inodes what we can use when we fetch information
about targets and put it into fdinfo output.

Al, Bruce, Aneesh,

What if we calculate the handle at the time we do have struct path at hands (i.e.
when we create the inotify) and store it on the inotify structure purely to be 
shown later in proc. Would that be acceptable?

Was it the lack of a dentry that was really the problem?  I thought it
was just the fact that not all filesystems support filehandles.

Initial problem -- we don't know what is being watched by an inotify fd.

Having a dentry somewhere was the 1st attempt to solve this -- keep a path
in inotify and show it when required. It doesn't work since holding a ref on
path changes the behavior of watched inode (we cannot rename/unlink/remount
it the same way as we could before patching the kernel).

OK.  So if you don't mind the fact that there are filesystems with
inotify support but not filehandle support, then I think generating a
filehandle early as you describe would work.  I guess it's a little more
memory per watched inode.

--b.