Re: ecryptfs

[Josef Sipek <jsipek@fsl.cs.sunysb.edu>]

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.

> Note that Unionfs
> has a persistent inode approach that is much more heavy-weight than
> this approach, but it does not need to modify anything in the VFS.

I'd just like to point out, that we'd (Unionfs folks) love to see a solution
at the VFS level.

> I would like the CONFIG_STACK_FS to govern VFS modifications that make
> stackable filesystems more functional. My approach is to allow the kernel
> to be built without any such modifications, but certain features will be
> disabled/degraded in the stacked filesystem.
 
Makes sense.

> +		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).

Josef "Jeff" Sipek.

-- 
Intellectuals solve problems; geniuses prevent them
		- Albert Einstein