[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: db(3) removal and lastlogx
On Fri, Jul 06, 2012 at 08:25:39PM +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
>> 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.
Do I? I usually do du * | sort -n, but anyway, the argument here seems
to be that people who don't know what they're doing might be confused
by sparse files, so therefore they shouldn't be used.
This seems like a poor line of reasoning.
>>> - 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.
A procedure more typical of the large installations I've used/worked
on would be to do echo -n > /var/log/lastlog once every couple years.
We've already expended more energy arguing about this than the issue
David A. Holland
Main Index |
Thread Index |