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 - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
