[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5033864A.5040809@parallels.com>
Date: Tue, 21 Aug 2012 16:59:54 +0400
From: Pavel Emelyanov <xemul@...allels.com>
To: Boaz Harrosh <bharrosh@...asas.com>
CC: "J. Bruce Fields" <bfields@...ldses.org>,
"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
Al Viro <viro@...iv.linux.org.uk>,
Cyrill Gorcunov <gorcunov@...nvz.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
Alexey Dobriyan <adobriyan@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
James Bottomley <jbottomley@...allels.com>,
Matthew Helsley <matt.helsley@...il.com>
Subject: Re: [patch 4/8] fs, exportfs: Add export_encode_inode_fh helper
On 08/21/2012 04:51 PM, Boaz Harrosh wrote:
> On 08/21/2012 03:29 PM, J. Bruce Fields wrote:
> <>
>
>> 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.
>>
>
>
> For the minority of FSs that do not have a filehandle support it should
> be easy to generate a generic one, that should work 95% of the time.
Yup, this is how exportfd_encode_fh currently works.
> Are we guaranteed that after the checkpoint restore the version of
> the Kernel is the same as the one that did the checkpoint? If yes
> then I don't see any problem.
Strictly speaking -- no we don't. Migration should to work across kernel
versions (from older to newer). Why kernel version matters in this case?
>> --b.
>
>
> Cheers
> Boaz
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists