Kernel Bug Tracker – Bug 14422
EXT4 is corrupted after clean shutdown
Last modified: 2009-10-27 11:47: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/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
Created attachment 23435 [details]
Created attachment 23436 [details]
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?
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
It's not hardware or architecture related. Conformed on Asus, Kubuntu x86_32 with 2.6.32-rc5
We can try to reproduce, but if there is any possibility of attaching actual e2fsck output, that would be most helpful.
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...
Can you try this patch ?
Author: Aneesh Kumar K.V <firstname.lastname@example.org>
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 <email@example.com>
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 5c5bc5d..a1ef1c3 100644
@@ -209,6 +209,12 @@ static int try_to_extend_transaction(handle_t *handle, struct inode *inode)
ret = ext4_journal_restart(handle, blocks_for_truncate(inode));
+ * 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
*** This bug has been marked as a duplicate of bug 14354 ***