Bug 14422 - EXT4 is corrupted after clean shutdown
EXT4 is corrupted after clean shutdown
Status: RESOLVED DUPLICATE of bug 14354
Product: File System
Classification: Unclassified
Component: ext4
All Linux
: P1 blocking
Assigned To: fs_ext4@kernel-bugs.osdl.org
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-10-16 18:31 UTC by David Heidelberg (okias)
Modified: 2009-10-27 11:47 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.32-rc1 - rc5
Tree: Mainline
Regression: Yes


Attachments
dmesg (45.36 KB, text/plain)
2009-10-16 18:33 UTC, David Heidelberg (okias)
Details
lspci (14.77 KB, text/plain)
2009-10-16 18:33 UTC, David Heidelberg (okias)
Details

Description David Heidelberg (okias) 2009-10-16 18:31:53 UTC
HW: Toshiba a210-15j
OS: Ubuntu Karmic 9.10 - 64bit
Kernel: 2.6.32-rc1 - rc5

/dev/sda1 /boot 100M ext2
/dev/sda2 / 10G ext4
/dev/sda3 swap
/dev/sda4 /home 100G ext4

After clean shutdown is corrupted lastest used files (KDE configuration, dpkg /var/cache ... ) on /dev/sda2 sometimes even /dev/sda4

It was repeated several times.

It's really similiar to http://lkml.indiana.edu/hypermail/linux/kernel/0910.1/02661.html
Comment 1 David Heidelberg (okias) 2009-10-16 18:33:11 UTC
Created attachment 23435 [details]
dmesg
Comment 2 David Heidelberg (okias) 2009-10-16 18:33:54 UTC
Created attachment 23436 [details]
lspci
Comment 3 Eric Sandeen 2009-10-16 23:44:12 UTC
When stating that a filesystem is corrupted, please offer some indication of why you believe this to be true; kernel messages indicating on-disk problems, fsck output, or at least the behavior you see which indicates corruption.  Otherwise there is simply not enough information to begin any investigation.

If those latest used files are corrupted - how are they corrupted?  missing?  short?  full of junk?  unreadable? or what?

Thanks,
-Eric
Comment 4 David Heidelberg (okias) 2009-10-17 07:03:41 UTC
fsck.ext4 automatic control fail after reboot. Then if I run manually fsck /dev/sda2, it write something about shared inode between two files or something like that. After lot of "yyyyyyyy" it copy some parts of files into /lost+found I'm not 100% sure, but parts of files are in lost+found and parts remain on it's old location.

I like to provide fsck logs, but I don't want corrupt my fs again... it's 100% regression, with =< 2.6.31 problem newer appeared
Comment 5 David Heidelberg (okias) 2009-10-22 13:01:41 UTC
It's not hardware or architecture related. Conformed on Asus, Kubuntu x86_32 with 2.6.32-rc5
Comment 6 Eric Sandeen 2009-10-22 14:54:08 UTC
We can try to reproduce, but if there is any possibility of attaching actual e2fsck output, that would be most helpful.

thanks,
-Eric
Comment 7 David Heidelberg (okias) 2009-10-23 09:11:13 UTC
Sorry, I can't do that for now. I can offer you steps to reproduce problem

1. Install Kubuntu 9.10 32 or 64bit (for example from Beta image)
2. sda1 /boot about 100M ext2, sda2 / 10G ext4, sda3 swap, sda4 /home ext4...
3. download from this location kernel - http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32-rc5/
4. At least 20x correctly shudown machine, until you hit issue... you probably hit this issue on every machine...
Comment 8 Aneesh Kumar K.V 2009-10-27 10:01:27 UTC
Can you try this patch ?

commit a8836b1d6f92273e001012c7705ae8f4c3d5fb65
Author: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Date:   Tue Oct 27 15:36:38 2009 +0530

    ext4: discard preallocation during truncate
    
    We need to make sure when we drop and reacquire the inode's
    i_data_sem we discard the inode preallocation. Otherwise we
    could have blocks marked as free in bitmap but still belonging
    to prealloc space.
    
    Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 5c5bc5d..a1ef1c3 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -209,6 +209,12 @@ static int try_to_extend_transaction(handle_t *handle, struct inode *inode)
 	up_write(&EXT4_I(inode)->i_data_sem);
 	ret = ext4_journal_restart(handle, blocks_for_truncate(inode));
 	down_write(&EXT4_I(inode)->i_data_sem);
+	/*
+	 * We have dropped i_data_sem. So somebody else could have done
+	 * block allocation. So discard the prealloc space created as a
+	 * part of block allocation
+	 */
+	ext4_discard_preallocations(inode);
 
 	return ret;
 }
Comment 9 David Heidelberg (okias) 2009-10-27 11:47:53 UTC

*** This bug has been marked as a duplicate of bug 14354 ***

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