Re: [patch 4/8] fs, exportfs: Add export_encode_inode_fh helper

[Pavel Emelyanov <xemul@parallels.com>]

On 08/21/2012 04:09 PM, J. Bruce Fields wrote:
> On Tue, Aug 21, 2012 at 02:49:47PM +0400, Pavel Emelyanov wrote:
>> On 08/21/2012 02:42 PM, Aneesh Kumar K.V wrote:
>>> Pavel Emelyanov <xemul@parallels.com> writes:
>>>
>>>> On 08/20/2012 11:32 PM, J. Bruce Fields wrote:
>>>>> On Mon, Aug 20, 2012 at 11:06:06PM +0400, Cyrill Gorcunov wrote:
>>>>>> On Mon, Aug 20, 2012 at 02:32:25PM -0400, J. Bruce Fields wrote:
>>>>>>> On Mon, Aug 20, 2012 at 08:33:38PM +0400, Cyrill Gorcunov wrote:
>>>>>>>> On Mon, Aug 20, 2012 at 07:49:23PM +0530, Aneesh Kumar K.V wrote:
>>>>>>>>> Cyrill Gorcunov <gorcunov@openvz.org> writes:
>>>>>>>>>
>>>>>>>>>> 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
> 
> OK.  Then you don't care about unlinked files?

Yes. If it's unlinked file, we can emulate this on restore with opening any path,
then unlinking it. The inode number will change, yes, but in many cases this is
acceptable trade-off.

> If the filesystem's frozen by the time you get here, I suppose you could
> also just use paths?

Sure, but where can we get the path from? This is what we're trying to resolve.

>>>> 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.
> 
> If it's a real filehandle you want, in general you don't want to
> construct it in userspace--depending on the filesystem it may require
> filesystem-specific knowledge.

I see.

> --b.

Thanks,
Pavel