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 <bouyer%antioche.eu.org@localhost>
NetBSD: 26 ans d'experience feront toujours la difference
--
Home |
Main Index |
Thread Index |
Old Index