Hi,
Can any of you explain this weirdness:
[root@machine log]# cd /var/log/ [root@machine log]# ls -la|grep last -r-------- 1 root root 1254130450140 Nov 6 21:44 lastlog [root@machine log]# du -hs lastlog 52K lastlog
What's up with the output of ls? This is x86_64.
Thanks,
Morten
On Sun, 2005-11-06 at 21:48 +0100, Morten wrote:
Hi,
Can any of you explain this weirdness:
[root@machine log]# cd /var/log/ [root@machine log]# ls -la|grep last -r-------- 1 root root 1254130450140 Nov 6 21:44 lastlog [root@machine log]# du -hs lastlog 52K lastlog
What's up with the output of ls? This is x86_64.
Thanks,
Morten
There was a thread about this some time back.. you can safely delete the file, then touch the filename and all will be well. There also was, I believe, a bugzilla about it somewhere upstream.
Sam
On Sun, Nov 06, 2005 at 04:16:21PM -0500, Sam Drinkard enlightened us:
Hi, Can any of you explain this weirdness:
[root@machine log]# cd /var/log/ [root@machine log]# ls -la|grep last -r-------- 1 root root 1254130450140 Nov 6 21:44 lastlog [root@machine log]# du -hs lastlog 52K lastlog
What's up with the output of ls? This is x86_64.
Thanks,
Morten
There was a thread about this some time back.. you can safely delete the file, then touch the filename and all will be well. There also was, I believe, a bugzilla about it somewhere upstream.
There have been a couple. The deal is that lastlog is a sparse file that is indexed by UID. On an x86_64 system, UIDs are 32-bit, which means a 1.2TB file, but because it's sparse, it doesn't actually take up any disk space.
There is some explanation here:
https://www.redhat.com/archives/fedora-test-list/2005-June/msg00308.html
Or you can search bugzilla for lastlog.
Matt
On Sun, 2005-11-06 at 16:00, Matt Hyclak wrote:
There have been a couple. The deal is that lastlog is a sparse file that is indexed by UID. On an x86_64 system, UIDs are 32-bit, which means a 1.2TB file, but because it's sparse, it doesn't actually take up any disk space.
It does make a good test case for whether your backup method handles sparse files gracefully, though. And how long it takes to read through even if it does.
On Sunday 06 November 2005 15:38, Les Mikesell wrote:
It does make a good test case for whether your backup method handles sparse files gracefully, though. And how long it takes to read through even if it does.
Which is exactly how I identified the problem. Our disk2disk backups (via rsync) got plowed when we installed a new CentOS 4.1 system and we ended up with a lastlog many times the size of the total disk space in the backup cluster.
Argh...
On Sun, 6 Nov 2005 at 9:48pm, Morten wrote
[root@machine log]# cd /var/log/ [root@machine log]# ls -la|grep last -r-------- 1 root root 1254130450140 Nov 6 21:44 lastlog [root@machine log]# du -hs lastlog 52K lastlog
What's up with the output of ls? This is x86_64.
nfsnobody has a UID of -1 (or something like that), casuing lastlog (which incorporates UIDs) to appear that enormous. Note that it's a sparse file, so it actually takes up very little space on disk. Run 'du' on it to see how much actual disk space it occupies.
-
Benjamin Smith -
Joshua Baker-LePain -
Les Mikesell -
Matt Hyclak -
Morten -
Sam Drinkard