Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 156591 - silent corruption for ext3 (very large file)
Summary: silent corruption for ext3 (very large file)
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 3
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-05-02 09:15 UTC by Arenas Belon, Carlo Marcelo
Modified: 2015-01-04 22:19 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-05-02 19:24:31 UTC

Attachments (Terms of Use)

Description Arenas Belon, Carlo Marcelo 2005-05-02 09:15:57 UTC
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
                       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):

How reproducible:

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

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 19:24:31 UTC
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.