mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Josef Sipek <jsipek@fsl.cs.sunysb.edu>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Erez Zadok <ezk@cs.sunysb.edu>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	mhalcrow@us.ibm.com, phillip@hellewell.homeip.net
Subject: Re: Re: [RFC/PATCH 1/2] stackfs: generic functions for obtaining hidden object
Date: Fri, 13 Oct 2006 13:23:04 -0400	[thread overview]
Message-ID: <20061013172304.GE3936@filer.fsl.cs.sunysb.edu> (raw)
In-Reply-To: <84144f020610130923q28d816ddl388484421e23ba91@mail.gmail.com>

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

      reply	other threads:[~2006-10-13 17:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-13 13:22 Pekka J Enberg
2006-10-13 13:40 ` Josef Sipek
2006-10-13 15:43 ` Erez Zadok
2006-10-13 16:23   ` Pekka Enberg
2006-10-13 17:23     ` Josef Sipek [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20061013172304.GE3936@filer.fsl.cs.sunysb.edu \
    --to=jsipek@fsl.cs.sunysb.edu \
    --cc=ezk@cs.sunysb.edu \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhalcrow@us.ibm.com \
    --cc=penberg@cs.helsinki.fi \
    --cc=phillip@hellewell.homeip.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®