Re: db(3) removal and lastlogx

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

On Fri, Jun 08, 2012 at 09:24:54PM +0100, David Laight wrote:
> On Fri, Jun 08, 2012 at 09:56:28PM +0200, Joerg Sonnenberger wrote:
> > On Thu, Jun 07, 2012 at 08:36:36AM +0200, Joerg Sonnenberger wrote:
> > > (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.
> > 
> > After some thinking, I will go with this route. File format will look
> > like:
> > 
> > magic number
> > record size
> 
> Must be worth adding some extra 0 bytes here.

Sure.

> > 64KB of used bytes, set if any uid / 64K is present.
> > 
> > 64K blocks of:
> {
> > 64KB of used bytes, set if uid / 64K matches the block number and uid %
> > 64K is present.
> > 
> > 64K records of given size
> }
> 
> I not sure I follow the above, possibly some { ... } might help!
> 
> I presume the byte maps are intended to make it possible to scan for
> used uid values without using the 'skip hole in file' functions?

Yes, exactly.

> > Each record gets has a version number at the beginning.
> 
> Why put it there?
> Given the record sizes are fixed it is extremely unlikely you can
> change the format of an entry.

Record size can be extended as long as the first program to write to the
file is using the largest known record size. That's the reason for
recording it at the beginning of the file.

> I think your access scheme is:
> 
> Most accesses are writes, so the code must read the file header first
> to verify the magic etc.
> So the header could contain the offest to the first block as well.
> It can then read the required entry before writing it back, if the
> read value was all-zero it must write out the two marker bytes.

Actually, the other way around. First write the entry and then check if
the marker bytes are set.

Joerg