tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: db(3) removal and lastlogx

On Sun, Jun 24, 2012 at 09:24:52PM +0000, David Holland wrote:
> On Mon, Jun 11, 2012 at 08:46:21PM +0200, Manuel Bouyer wrote:
>  >>>>> With 32bit uids, this will be very large files. We should avoid this.
>  >>>> 
>  >>>> Only if you carefully choose your UID space relative to the file
>  >>>> system block size to maximize the amount of unused space that must
>  >>>> nonetheless be materialized. That is foolish.
>  >>> 
>  >>> My UID space is not dense, but I meant large by what's displayed with ls 
> -l.
>  >> 
>  >> And that's important how?
>  > 
>  > - people usually uses ls -l to find what could free some space on a full
>  >  filesystem
> They should know to use du.

You usually use du to find usage per-directory and ls -l in each
directory to find big files. 

>  > - some tools don't deal with sparse files.
> Which mostly doesn't matter. Especially with the lastlog file, which
> is not exactly valuable data and can be (and routinely is) blown away
> if a problem arises.

But before you've blown it away you created a problem.

>  > - once a block has been allocated, it won't ever be freed unless you kill
>  >   the file.
> It is easier to work around this than to worry about it, e.g. by
> zeroing out lastlog records when accounts are removed, and then once a
> year running a program that reclaims zero space as holes.

So we have a new program to work around the issue.

this shows that sparse files gives more troubles than it's worth.

Manuel Bouyer <>
     NetBSD: 26 ans d'experience feront toujours la difference

Home | Main Index | Thread Index | Old Index