On 08/20/2012 11:32 PM, J. Bruce Fields wrote:

On Mon, Aug 20, 2012 at 11:06:06PM +0400, Cyrill Gorcunov wrote:

quoted

On Mon, Aug 20, 2012 at 02:32:25PM -0400, J. Bruce Fields wrote:

quoted

On Mon, Aug 20, 2012 at 08:33:38PM +0400, Cyrill Gorcunov wrote:

quoted

On Mon, Aug 20, 2012 at 07:49:23PM +0530, Aneesh Kumar K.V wrote:

quoted

Cyrill Gorcunov [off-list ref] writes:

quoted

To provide fsnotify object inodes being watched without
binding to alphabetical path we need to encode them with
exportfs help. This patch adds a helper which operates
with plain inodes directly.

doesn't name_to_handle_at()  work for you ? It also allows to get a file
handle using file descriptor.

Hi, sorry for dealy. Well, the last idea is to get rid of this helper,
I've sent out an updated version where ino+dev is only printed.

I don't understand how ino and dev are useful to you, though, if you're
still hoping to be able to look up inodes using this information later
on.

Hi Bruce, I believe having ino+dev is better than nothing. Otherwise we
simply have no clue which targets are bound to inotify mark. Sometime
(!) we can try to generate fhandle in userspace from this ino+dev bundle
and then open the target file.

That's insufficient to generate a filehandle in general.

Yes, sure, but for live migration having inode and device is enough and that's why.
We can use two ways of having a filesystem on the target machine in the same
state (from paths points of view) as it was on destination one:

1. copy file tree in a rsync manner
2. copy a virtual disk image file

In the 1st case we can map inode number to path easily, since we iterate over a filesystem
anyway. I agree, that rsync is not perfect for migration but still.

In the 2nd case we can generate filehandle out of an inode number only since we _do_ know
that inode will not get reused.


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

(Also: there's the usual inode-number aliasing problem: the inode number
could get reused by another file.  Unless you know the file is being
held open the whole time.)

--b.
.

Thanks,
Pavel