On 01/02/2012 07:59 PM, Simo Sorce wrote:
> On Mon, 2012-01-02 at 15:47 -0900, Erinn Looney-Triggs wrote:
>> While digging through and trying to investigate a file system slowdown
>> that may or may not be IPA related, I noticed an odd thing on my RHEL 5
>> and 6 based systems, the lastlog file was bloody huge:
>> -rw-r--r-- 1 root root 469419202628 Jan  3 00:20 /var/log/lastlog
>> Or for those of us who don't count that high .
>> -rw-r--r-- 1 root root 438G Jan  3 00:20 /var/log/lastlog
>> Now really it isn't that big:
>> erinn@uat ~ $ du -sh /var/log/lastlog
>> 64K     /var/log/lastlog
>> However, and I am no expert here, some backup programs will choke hard
>> on this file, because it appears all that empty space will actually get
>> nulled out, or at least this is happening to me with Bacula 5.0.2 on
>> RHEL 5. More investigation into this part is necessary though...
>> Now at a guess, this is probably related to this blog post:
>> http://linuxshellaccount.blogspot.com/2007/11/trimming-space-in-var-problem-with.html
>> That article was written for Solaris but it sure seems to be applicable
>> to Linux as well. Though the multiples aren't the same.
>> Frustratingly, this does not seem to be the case with all of my systems,
>> only some of them. I have multiple RHEL 5 and 6 instances exhibiting
>> this issue, and one RHEL 5 system that is not.
>> This is probably a result of IPA choosing ludicrously high UIDs to avoid
>> collisions (which is fine, no bashing here).
>> Can anyone else confirm? Lend more insight?
> I can confirm.
> apparently lastlog programmers decided that using sparse files to
> implement a hash table where the key is the uid number was a good
> idea ...
> Can you please file a bug against RHEL and CC me ?
> I am not sure what we do for RHEL5/RHEL6 as I don't know if the lastlof
> file format changes is considered an aBI change but we can certainly
> prevent this from happening in Fedora and RHEL7.
> I think, meanwhile you may want to exclude lastlog from backups or bzip2
> it before backing it up.
> Thanks for reporting this.
> Simo.

Done, thanks for confirming.


Attachment: signature.asc
Description: OpenPGP digital signature

Freeipa-users mailing list

Reply via email to