Hi, Can any of you explain this weirdness: [root at machine log]# cd /var/log/ [root at machine log]# ls -la|grep last -r-------- 1 root root 1254130450140 Nov 6 21:44 lastlog [root at 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 at machine log]# cd /var/log/ > [root at machine log]# ls -la|grep last > -r-------- 1 root root 1254130450140 Nov 6 21:44 lastlog > [root at 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>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos/attachments/20051106/34797db1/attachment.html>
On Sun, 6 Nov 2005 at 9:48pm, Morten wrote> [root at machine log]# cd /var/log/ > [root at machine log]# ls -la|grep last > -r-------- 1 root root 1254130450140 Nov 6 21:44 lastlog > [root at 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. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
On Sun, Nov 06, 2005 at 04:16:21PM -0500, Sam Drinkard enlightened us:> > Hi, > > Can any of you explain this weirdness: > > > > [root at machine log]# cd /var/log/ > > [root at machine log]# ls -la|grep last > > -r-------- 1 root root 1254130450140 Nov 6 21:44 lastlog > > [root at 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 -- Matt Hyclak Department of Mathematics Department of Social Work Ohio University (740) 593-1263
> > > > 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.Legato Networker packs a sad (it handles sparse files, but it takes a *very* long time to do so). ;-) C ======================================================================Attention: The information contained in this message and/or attachments from AgResearch Limited is intended only for the persons or entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipients is prohibited by AgResearch Limited. If you have received this message in error, please notify the sender immediately. =======================================================================