Re: db(3) removal and lastlogx

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Thu, Jun 07, 2012 at 09:07:44AM +0200, Alan Barrett wrote:
> On Thu, 07 Jun 2012, Joerg Sonnenberger wrote:
> >The last real consume of the db(3) API in libc is the lastlogx
> >handling in utmpx. Basically, this logs a record in a file indexed
> >by uid. I can think of three different approaches for dealing with
> >this:
> >
> >(1) Just use a sparse file. This requires by far the least amount
> >of code, just some verification logic for a file header and
> >writing to "uid * size of entry". Writes should be short enough to
> >ensure atomic writes even on NFS. Same for reads. No manual
> >locking needed.
> 
> With 32-bit uid_t, the file size could appear to be multiple
> gigabytes, even though not that much space is actually used.  This
> might confuse people and naive copy or backup processes.

Only if you actually use uids that large.

> >(2) Implement a simple hierachical byte-level index, [...]
> >(3) Implement on-disk PATRICA lookup. [...]
> 
> (4) Use sqlite.

This is still libc we are talking about. So no, sqlite is not
acceptable.

> (0) continue to use db(3).

I don't really consider this an option either. Especially for a file
where updates happen all the time and e.g. the crash reliability of
db(3) is a real concern.

Joerg