From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050416 Fedora/1.0.3-1.3.1 Firefox/1.0.3 Description of problem: a very large file (/var/log/lastlog) which isn't really that big. heard of a similar problem reported some time ago on the kernel list and which was fixed with an fsck but no data was gathered first for debuging purposes. the problem can be seen below : [root@laptop log]# ls -al lastlog sta-r-------- 1 root root 1254130450140 May 1 23:39 lastlog [root@laptop log]# stat lastlog File: `lastlog' Size: 1254130450140 Blocks: 104 IO Block: 4096 regular file Device: fd00h/64768d Inode: 1370904 Links: 1 Access: (0400/-r--------) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2005-05-01 23:47:15.000000000 -0700 Modify: 2005-05-01 23:39:50.000000000 -0700 Change: 2005-05-01 23:39:50.000000000 -0700 [root@laptop log]# df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/fedora-root 16G 9.9G 5.1G 66% / /dev/hda2 122M 32M 84M 28% /boot none 249M 0 249M 0% /dev/shm /dev/sda1 113G 58G 55G 52% /media/usbdisk my guess is that the real file is probably 64K (as shown by the blocks count), information from debugfs shows : debugfs: stat /var/log/lastlog Inode: 1370904 Type: regular Mode: 0400 Flags: 0x0 Generation: 2186819905 User: 0 Group: 0 Size: 1254130450140 File ACL: 2753026 Directory ACL: 0 Links: 1 Blockcount: 104 Fragment: Address: 0 Number: 0 Size: 0 ctime: 0x4275cb36 -- Sun May 1 23:39:50 2005 atime: 0x4275ccf3 -- Sun May 1 23:47:15 2005 mtime: 0x4275cb36 -- Sun May 1 23:39:50 2005 BLOCKS: (0):2775207, (1-3):2781184-2781186, (4):2775040, (5):2782094, (IND):2787779, (35):2787780, (TIND):2783036, (DIND):2783037, (IND):2783038, (306184191):2783039 TOTAL: 12 Version-Release number of selected component (if applicable): kernel-2.6.11-1.14_FC3 How reproducible: Always Steps to Reproduce: 1. cd /var/log 2. ls -al lastlog 3. Actual Results: see huge file size which doesn't reflect usage for the filesystem and which doesn't seem to have the right number of blocks assigned to it. Expected Results: a normal file Additional info: not sure how the file got into such status, there are no messages or anything on the logs which can explain why it is like that or even if it is happenning (it is silent, as there is no visible message or error while accessing the file either)
this is expected behaviour. its a sparse file, so it doesn't use as much disk space as the size of the file. Only the non-zero parts of the file take up disk space. x86-64 has potential for a huge number of UIDs, hence the file appears much larger, even if those uid's aren't in use.