From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Halcrow Subject: Re: ecryptfs Date: Mon, 7 Aug 2006 17:47:36 -0500 Message-ID: <20060807224736.GI2883@us.ibm.com> References: <20060805140237.2226a9dc.akpm@osdl.org> <20060807161939.GC2950@us.ibm.com> <20060807163115.GA4028@us.ibm.com> <20060807172104.GA30519@filer.fsl.cs.sunysb.edu> Reply-To: Michael Halcrow Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andrew Morton , Christoph Hellwig , linux-fsdevel@vger.kernel.org Return-path: Received: from e33.co.us.ibm.com ([32.97.110.151]:32484 "EHLO e33.co.us.ibm.com") by vger.kernel.org with ESMTP id S932316AbWHGWrj (ORCPT ); Mon, 7 Aug 2006 18:47:39 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k77Mlc2q013598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 7 Aug 2006 18:47:39 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k77Mlb0t195560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 7 Aug 2006 16:47:38 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k77Mlaqb025812 for ; Mon, 7 Aug 2006 16:47:37 -0600 To: Josef Sipek Content-Disposition: inline In-Reply-To: <20060807172104.GA30519@filer.fsl.cs.sunysb.edu> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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. > > + inode->i_private = NULL; > > +#ifdef CONFIG_STACK_FS > > + inode->i_stacked_inode = NULL; > > +#endif > > inode->i_mapping = mapping; > > Hrm. Looking at this made me think...This patch introduces pointers > up the stack in the VFS. Would it make sense to introduce the down > pointers as well, and make ecryptfs, et. al., depend on STACK_FS? > This would clean up some of the use of private data. Of course these > pointers (the up & down) make struct inode grow 8 bytes (on 32-bit > systems). I would say that using the existing private data pointer is a better option than consuming more space in each and every inode struct. Mike