Pavel Emelyanov [off-list ref] writes:

On 08/21/2012 02:42 PM, Aneesh Kumar K.V wrote:

quoted

Pavel Emelyanov [off-list ref] writes:

quoted

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

quoted

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.

If you are going to to use open_by_handle, then that handle is not
sufficient right ? Or do you have open_by_inode ? as part of c/r ?

Why? For e.g. ext4 you can construct a handle in userspace and open by
it.

open_by_handle use exportfs_decode_fh which use file system specific
fh_to_dentry

foe ext4 we require a generation number

		inode = get_inode(sb, fid->i32.ino, fid->i32.gen);

For brtfs

	objectid = fid->objectid;
	root_objectid = fid->root_objectid;
	generation = fid->gen;

	return btrfs_get_dentry(sb, objectid, root_objectid, generation, 1);

-aneesh