Skipped groups in idmap2 on a cluster (with CTDB and GPFS)

[Volker Lendecke]

Hi, Richard!

It should never happen that the idmap2.tdb is different on
different nodes. That file is being covered by ctdb
transactions, which are supposed to take care of making sure
that they are the same everywhere. Can you say when this
happened?

Volker


On Wed, May 25, 2011 at 02:58:32PM -0700, Richard Sharpe wrote:
> On Tue, May 24, 2011 at 1:42 PM, Richard Sharpe
> <realrichardsharpe at gmail.com> wrote:
> > Hi,
> >
> > Has anyone seen cases where group numbers have been skipped (ie, not allocated).
> >
> > We are allocating numbers up in the range 16777216 and up.
> >
> > I am investigating a problem and I find that the output from wbinfo -G
> > from 16777309 to 16777320 shows a gap of unallocated GIDs from
> > 16777310 to 16777313.
> >
> > However, there is a file/dir that was created via Samba that has the
> > GID 16777312 in its ACL.
> >
> > Any suggestions on what has happened?
> 
> Further on this, if I do tdbdump on two nodes in the cluster and grep
> for 16777312, I see:
> 
> tdbdump /ctdb/persistent/idmap2.tdb.1 | grep 16777312
> key(13) = "GID 16777312\00"
> key(13) = "UID 16777312\00"
> data(37) = "\01\00\00\00\00\00\00\00\01\00\00\00\02\00\00\00\00\00\00\00\00\00\00\00UID
> 16777312\00"
> 
> and on one node I see:
> 
> tdbdump idmap2.tdb.2 | grep 16777312
> key(13) = "UID 16777312\00"
> data(37) = "\01\00\00\00\00\00\00\00\01\00\00\00\02\00\00\00\00\00\00\00\00\00\00\00UID
> 16777312\00"
> 
> Thus it would appear that there is a problem in that two nodes have a
> key for GID 16777312 but no data.
> 
> Is this normal?
> 
> -- 
> Regards,
> Richard Sharpe

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen