From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shaya Potter Subject: Re: ecryptfs Date: Tue, 08 Aug 2006 11:10:49 -0400 Message-ID: <44D8A979.6050900@cs.columbia.edu> References: <20060805140237.2226a9dc.akpm@osdl.org> <20060807161939.GC2950@us.ibm.com> <20060807163115.GA4028@us.ibm.com> <20060807172104.GA30519@filer.fsl.cs.sunysb.edu> <20060807224736.GI2883@us.ibm.com> <1154995990.4585.0.camel@localhost.localdomain> <20060808143126.GA2908@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Josef Sipek , Andrew Morton , Christoph Hellwig , linux-fsdevel@vger.kernel.org Return-path: Received: from e36.co.us.ibm.com ([32.97.110.154]:194 "EHLO e36.co.us.ibm.com") by vger.kernel.org with ESMTP id S964943AbWHHPKv (ORCPT ); Tue, 8 Aug 2006 11:10:51 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e36.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k78FApbA031335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 8 Aug 2006 11:10:51 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay02.boulder.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k78FAooB160436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 8 Aug 2006 09:10:50 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k78FAnBq028221 for ; Tue, 8 Aug 2006 09:10:50 -0600 To: Michael Halcrow In-Reply-To: <20060808143126.GA2908@us.ibm.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Michael Halcrow wrote: > On Mon, Aug 07, 2006 at 08:13:10PM -0400, Shaya Potter wrote: >> On Mon, 2006-08-07 at 17:47 -0500, Michael Halcrow wrote: >>> On Mon, Aug 07, 2006 at 01:21:04PM -0400, Josef Sipek wrote: >>>> On Mon, Aug 07, 2006 at 11:31:15AM -0500, Michael Halcrow wrote: >>>> ... >>>>> Here is where I am thinking about going with crossing lower mount >>>>> points. This patch makes sure that there is a 1-to-1 mapping in >>>>> inode numbers between the stacked inodes and the lower inodes. It >>>>> maintains the association by modifying the struct inode to include >>>>> a back pointer from the lower inode to the stacked inode. >>>> Do you maintain the inode numbers across mounts (of ecryptfs)? The >>>> patch doesn't look like it does. >>> Nope; this patch just aims to make sure that stacked and lower inodes >>> maintain a 1-to-1 relationship. >> so that won't let your cross mount points.... i.e. the 2 underlying >> mountpoints can have the same inode numbers, couldn't they? > > Two underlying mountpoints can have the sane inode number. This patch > will assign a unique inode number to each stacked inode while linking > to the stacked inode from the lower inode to keep a 1-to-1 mapping of > stacked and lower inodes. Something like this is necessary for > crossing mount points in the lower filesystem while handling hard > links right. There are other issues with regard to namespaces and what > not that still need to be addressed. ok, I understand, your mention of unionfs's persistent inodes confused me.