Re: [PATCH 03/10] idr: Rewrite ida

[Kent Overstreet <koverstreet@google.com>]

On Wed, Jun 19, 2013 at 10:40:22AM +0100, Steven Whitehouse wrote:
> Hi,
> 
> On Tue, 2013-06-18 at 17:02 -0700, Kent Overstreet wrote:
> > This is a new, from scratch implementation of ida that should be
> > simpler, faster and more space efficient.
> > 
> [...]
> 
> > 
> > This does mean that the entire bitmap is stored in one contiguous memory
> > allocation - and as currently implemented we won't be able to allocate
> > _quite_ as many ids as with the previous implementation.
> > 
> > I don't expect this to be an issue in practice since anywhere this is
> > used, an id corresponds to a struct allocation somewher else - we can't
> > allocate an unbounded number of ids, we'll run out of memory somewhere
> > else eventually, and I expect that to be the limiting factor in
> > practice.
> > 
> > If a user/use case does come up where this matters I can add some
> > sharding (or perhaps add a separate big_ida implementation) - but the
> > extra complexity would adversely affect performance for the users that
> > don't need > millions of ids, so I intend to leave the implementation as
> > is until if and when this becomes an issue.
> > 
> 
> Millions of IDs is something that is fairly normal for DLM, since there
> will be two DLM locks per cached inode with GFS2 and people tend to use
> it on pretty large servers with lots of memory,

Thanks, I wasn't aware of that. Is the 31 bits for the id limitation an
issue for you? While I'm at changing ids to longs should be fairly
trivial.