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:
> 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
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 Sorce * Red Hat, Inc * New York
Freeipa-users mailing list