From Bugzilla Helper: User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.5-0.4smp i686) Description of problem: I'm running Linux version 2.4.5-0.4smp. Something is going wrong with the ext3 module in the way it handles the number of blocks occupied by a file : [root@monkey /mnt]# mount /tmp/dummy.img /mnt/ext3 -oloop -text3 [root@monkey /mnt]# echo foooooooo > /mnt/ext3/foo [root@monkey /mnt]# stat /mnt/ext3/foo File: "/mnt/ext3/foo" Size: 10 Blocks: 0 Regular File Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Device: 700 Inode: 12 Links: 1 Access: Thu Jun 21 15:54:51 2001 Modify: Thu Jun 21 15:54:51 2001 Change: Thu Jun 21 15:54:51 2001 [root@monkey /mnt]# umount /mnt/ext3 [root@monkey /mnt]# /sbin/fsck.ext2 -y -f /tmp/dummy.img e2fsck 1.21, 15-Jun-2001 for EXT2 FS 0.5b, 95/08/09 Pass 1: Checking inodes, blocks, and sizes Inode 12, i_blocks is 0, should be 2. Fix? yes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Block bitmap differences: -1306 Fix? yes Free blocks count wrong for group #0 (6886, counted=6887). Fix? yes Free blocks count wrong (6886, counted=6887). Fix? yes /tmp/dummy.img: ***** FILE SYSTEM WAS MODIFIED ***** /tmp/dummy.img: 12/2048 files (0.0% non-contiguous), 1305/8192 blocks ---> used blocks is zero as reported by stat. Free disk space decreases abnormaly as the filesystem is used. How reproducible: Always Steps to Reproduce: 1. mount an ext3 filesystem 2. 3. Additional info: (Bug introduced in 2.4.5-0.4. Same behaviour in both smp and up kernel.)
Did you test a previous ext3 kernel and if so, did it have the same behavior ?
ext3 was running fine on the previous rawhide kernel (2.4.5-0.2.9 up). [a self recompiled version from the SRPM, with CONFIG_JBD_DEBUG enabled]
After having a look at the code differences between 2.4.5-0.2.9 and 2.4.5-0.4, I noticed that some code related to inode->i_blocks has been commented out in the later version : --- /usr/src/linux-2.4.5/fs/ext3/inode.c Mon Jun 18 11:05:37 2001 +++ fs/ext3/inode.c Fri Jun 22 00:24:56 2001 @@ -590,7 +590,7 @@ *where->p = where->key; inode->u.ext3_i.i_next_alloc_block = block; inode->u.ext3_i.i_next_alloc_goal = le32_to_cpu(where[num-1].key); - /* inode->i_blocks += num * inode->i_sb->s_blocksize/512;*/ + inode->i_blocks += num * inode->i_sb->s_blocksize/512; /* Writer: end */ @@ -1343,7 +1343,7 @@ * We don't call ext3_mark_inode_dirty for ->i_blocks. That's taken * care of when we extend, and when we finish truncate */ - /* inode->i_blocks -= count * inode->i_sb->s_blocksize / 512; */ + inode->i_blocks -= count * inode->i_sb->s_blocksize / 512; } /** @@ -1505,7 +1505,7 @@ ext3_forget(handle, 1, inode, bh, bh->b_blocknr); /* Release the child block now */ - /* inode->i_blocks -= inode->i_sb->s_blocksize / 512; */ + inode->i_blocks -= inode->i_sb->s_blocksize / 512; ext3_free_blocks(handle, inode, nr, 1); http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gkernel/ext3/fs/ext3/inode.c?rev=1.39.4.1&content-type=text/vnd.viewcvs-markup contains this same code uncommented. This patch seems to work for me.
Yes, it was a patch merge fault which will be fixed in future builds.