Bug 14422
| Summary: | EXT4 is corrupted after clean shutdown | ||
|---|---|---|---|
| Product: | File System | Reporter: | David Heidelberg (david) |
| Component: | ext4 | Assignee: | fs_ext4 (fs_ext4) |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | blocking | CC: | sandeen |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.32-rc1 - rc5 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: |
dmesg
lspci |
||
|
Description
David Heidelberg
2009-10-16 18:31:53 UTC
Created attachment 23435 [details]
dmesg
Created attachment 23436 [details]
lspci
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 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. thanks, -Eric 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 ? 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; } |