This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 156591 - silent corruption for ext3 (very large file)
silent corruption for ext3 (very large file)
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
3
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-02 05:15 EDT by Arenas Belon, Carlo Marcelo
Modified: 2015-01-04 17:19 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-02 15:24:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Arenas Belon, Carlo Marcelo 2005-05-02 05:15:57 EDT
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)
Comment 1 Dave Jones 2005-05-02 15:24:31 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.