[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: db(3) removal and lastlogx
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
> >(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
> (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.
Main Index |
Thread Index |