Bug 45346 - ext3fs fails to set the number of used blocks
Summary: ext3fs fails to set the number of used blocks
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: kernel
Version: 1.0
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brock Organ
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-06-21 13:58 UTC by Fabrice Bellet
Modified: 2015-01-04 22:01 UTC (History)
2 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2004-10-30 03:40:49 UTC


Attachments (Terms of Use)

Description Fabrice Bellet 2001-06-21 13:58:44 UTC
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.)

Comment 1 Arjan van de Ven 2001-06-21 14:02:02 UTC
Did you test a previous ext3 kernel and if so, did it have the same behavior ?

Comment 2 Fabrice Bellet 2001-06-21 14:07:44 UTC
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]

Comment 3 Fabrice Bellet 2001-06-21 22:40:54 UTC
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.

Comment 4 Stephen Tweedie 2001-06-22 19:36:39 UTC
Yes, it was a patch merge fault which will be fixed in future builds.


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