Red Hat Bugzilla – Bug 156591
silent corruption for ext3 (very large file)
Last modified: 2015-01-04 17:19:23 EST
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
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
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
(0):2775207, (1-3):2781184-2781186, (4):2775040, (5):2782094, (IND):2787779, (35):2787780, (TIND):2783036, (DIND):2783037, (IND):2783038, (306184191):2783039
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. cd /var/log
2. ls -al lastlog
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
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.