From: David Jander Subject: Re: ext4: journal has aborted Date: Tue, 1 Jul 2014 15:50:04 +0200 Message-ID: <20140701155004.194b7ee8@archvile> References: <20140701082619.1ac77f1d@archvile> <20140701084206.GG9743@birch.djwong.org> <53B2A47F.90903@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "Darrick J. Wong" , Matteo Croce , linux-ext4@vger.kernel.org, "Theodore Ts'o" To: Jaehoon Chung Return-path: Received: from protonic.xs4all.nl ([83.163.252.89]:28624 "EHLO protonic.xs4all.nl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752862AbaGANuA (ORCPT ); Tue, 1 Jul 2014 09:50:00 -0400 In-Reply-To: <53B2A47F.90903@samsung.com> Sender: linux-ext4-owner@vger.kernel.org List-ID: Hi Jaehoon, On Tue, 01 Jul 2014 21:07:27 +0900 Jaehoon Chung wrote: > Hi, > > i have interesting for this problem..Because i also found the same problem.. > Is it Journal problem? > > I used the Linux version 3.16.0-rc3. > > [ 3.866449] EXT4-fs error (device mmcblk0p13): ext4_mb_generate_buddy:756: group 0, 20490 clusters in bitmap, 20488 in gd; block bitmap corrupt. > [ 3.877937] Aborting journal on device mmcblk0p13-8. > [ 3.885025] Kernel panic - not syncing: EXT4-fs (device mmcblk0p13): panic forced after error > [ 3.885025] > [ 3.891751] CPU: 1 PID: 1488 Comm: mv Not tainted 3.16.0-rc3-00206-gc0f4eea0-dirty #2 > [ 3.899594] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > [ 3.907294] [] (show_stack) from [] (dump_stack+0x78/0xc8) > [ 3.914495] [] (dump_stack) from [] (panic+0x8c/0x1f0) > [ 3.921354] [] (panic) from [] (ext4_handle_error+0x68/0xa8) > [ 3.928730] [] (ext4_handle_error) from [] (__ext4_grp_locked_error+0x88/0x1c0) > [ 3.937759] [] (__ext4_grp_locked_error) from [] (ext4_mb_generate_buddy+0x260/0x398) > [ 3.947306] [] (ext4_mb_generate_buddy) from [] (ext4_mb_init_cache+0x2fc/0x7fc) > [ 3.956433] [] (ext4_mb_init_cache) from [] (ext4_mb_init_group+0x1b8/0x234) > [ 3.965186] [] (ext4_mb_init_group) from [] (ext4_mb_load_buddy+0x34c/0x380) > [ 3.973952] [] (ext4_mb_load_buddy) from [] (ext4_free_blocks+0x47c/0xd30) > [ 3.982545] [] (ext4_free_blocks) from [] (ext4_ext_remove_space+0xae0/0x1474) > [ 3.991486] [] (ext4_ext_remove_space) from [] (ext4_ext_truncate+0xb4/0xd4) > [ 4.000251] [] (ext4_ext_truncate) from [] (ext4_truncate+0x37c/0x43c) > [ 4.008497] [] (ext4_truncate) from [] (ext4_evict_inode+0x334/0x4f4) > [ 4.016660] [] (ext4_evict_inode) from [] (evict+0x94/0x158) > [ 4.024036] [] (evict) from [] (__dentry_kill+0x1dc/0x22c) > [ 4.031238] [] (__dentry_kill) from [] (dput+0xa8/0x1ac) > [ 4.038282] [] (dput) from [] (SyS_renameat2+0x250/0x36c) > [ 4.045396] [] (SyS_renameat2) from [] (SyS_rename+0x28/0x30) > [ 4.052859] [] (SyS_rename) from [] (ret_fast_syscall+0x0/0x3c) > > I used with the eMMC card. I want to know the debugging point for this problem. > If anybody have solution, let me know, plz. You can try to disable the mount option "errors=panic", I suspect the actual error is harmless.... OTOH, then you cannot see the stack-trace anymore. AFAICS, it seems to originate in ext4_ext_remove_space() in all cases I have seen, and happens quicker if the filesystem was not unmounted properly, so maybe the bug is related to the journal code's accounting of free space. Let's wait and see what the experts say about this... Regards, -- David Jander Protonic Holland.