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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
