Messages in this thread | | | Date | Fri, 13 Oct 2006 13:23:04 -0400 | From | Josef Sipek <> | Subject | Re: Re: [RFC/PATCH 1/2] stackfs: generic functions for obtaining hidden object |
| |
On Fri, Oct 13, 2006 at 07:23:36PM +0300, Pekka Enberg wrote: > On 10/13/06, Erez Zadok <ezk@cs.sunysb.edu> wrote: > >I think we should do it right the first time (i.e., now :-) > > I would much rather merge it now (assuming I didn't break ecryptfs) > and have you unionfs developers fix it later :-).
Thanks :) As they say, it's the thought that counts, isn't it? ;)
> On 10/13/06, Erez Zadok <ezk@cs.sunysb.edu> wrote: > >Why not make it something more dynamic, such as a mount-time option per sb? > >Even at 8, you waste most of that space for non-fan-out stackable file > >systems such as ecryptfs; and those unionfs users who want more, will have > >to _recompile_ the code. > > Yes, we discussed this with Jeff already. For unionfs, we must make it > more dynamic. However, using slab unconditionally makes it totally > unacceptable for ecryptfs. Therefore, we need a small static array > that should satisfy most user (I think we can drop the static array > size to three):
Nice, 3 pointers to inodes, and one to inode* = 4 pointers total, 128/256 bit struct on i386/x86_64.
> struct stackfs_inode_info { > struct inode **hidden_inodes; > struct inode *static_inodes[3]; > }; > > Initially, hidden_inodes can point to static_inodes which we can the > replace with a dynamic array if required.
Hrm. You can have static store inodes {0,1,2} and the dynamic {3,4,5,...} (this is what unionfs used to do - inline objects for performance). The other way can be static array is ignored if dynamic array exists. In which case, you effectively have {} in static, and {0,1,2,3,4,5,...} in dynamic. I guess you could justify the wasting of the static array by arguing that if the number of branches is << than number of static array elements, but I'm afraid that that won't be the case most of the time.
> Btw, we probably want to do krealloc() for that in the slab allocator.
krealloc should be trivial to do (if the new size <= size of current slab, do nothing, else alloc from a larger one).
Josef "Jeff" Sipek.
-- We have joy, we have fun, we have Linux on a Sun... - 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/
| |