Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756711Ab2HOVCo (ORCPT ); Wed, 15 Aug 2012 17:02:44 -0400 Received: from mail-lb0-f174.google.com ([209.85.217.174]:40692 "EHLO mail-lb0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752476Ab2HOVCm (ORCPT ); Wed, 15 Aug 2012 17:02:42 -0400 Date: Thu, 16 Aug 2012 01:02:37 +0400 From: Cyrill Gorcunov To: "J. Bruce Fields" Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Al Viro , Alexey Dobriyan , Andrew Morton , Pavel Emelyanov , James Bottomley , Matthew Helsley Subject: Re: [patch 4/8] fs, exportfs: Add export_encode_inode_fh helper Message-ID: <20120815210237.GF25421@moon> References: <20120815092116.700948346@openvz.org> <20120815092409.591460800@openvz.org> <20120815204546.GC25062@fieldses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120815204546.GC25062@fieldses.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1464 Lines: 31 On Wed, Aug 15, 2012 at 04:45:46PM -0400, J. Bruce Fields wrote: > On Wed, Aug 15, 2012 at 01:21:20PM +0400, Cyrill Gorcunov wrote: > > 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. > > I don't get it--this seems like a really roundabout way to get inode and > generation number, if that's all you want. We can re-open the targets via filehandle on restore, this was the idea. All this series aimed to achieve the way to restore objects after checkpoit, thus we need to provide additional information which would be enough. > On the other hand, if you want a real filehandle then wouldn't you want > to e.g. call the filesystem's ->encode_fh() if necessary, as > exportfs_encode_fh() does? Well, one of the problem I hit when I've been trying to use encode_fh is that every new implementation of encode_fh will require some size (even unknown) in buffer where encoded data pushed. Correct me please if I'm wrong. But with export_encode_inode_fh there is a small buffer with pretty known size needed on stack needed for printing data in fdinfo. Cyrill -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/