Re: db(3) removal and lastlogx

[David Laight <david%l8s.co.uk@localhost>]

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.

> 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?

> 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.

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.

In practise this code isn't performance critical!

        David

-- 
David Laight: david%l8s.co.uk@localhost