Re: re problems with ext3 well if think it is

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Simon May <simon@imsl.es> wrote:
> We use kernel 2.4.18 with a slackware linux dist.
> e2fsprogs version 1.29
> 
> you will see that sendmail was the application that lead to the error
> at the time the machine was doing a weekly new letter to clients
> which puts it under abit of load but not a lot really
> the machine has a 1 Gb processor and 768 Mb RAM so is reasonably
> powerful.

Below is the oops and extracted stack trace:

    <0>Assertion failure in do_get_write_access() at transaction.c:589:
"handle->h_buffer_credits > 0"
    <4>invalid operand: 0000
    <4>CPU:    0
    <4>EIP:    0010:[<c015fb48>]    Not tainted
    <4>EFLAGS: 00010286
    <4>eax: 00000063   ebx: ead2ae20   ecx: ffffffff   edx: 00000001
    <4>esi: c1c7bae0   edi: c1c7bae0   ebp: c1c24000   esp: e7edfe34
    <4>ds: 0018   es: 0018   ss: 0018
    <4>Process sendmail (pid: 27413, stackpage=e7edf000)
    <4>Stack: c0254aa0 c0254eae c0254a80 0000024d c0254f61 c1c24000 e5e92a00 ead2ae20 
    <4>       c1c24094 c1c24094 00000000 00000000 c1c24000 cd05a5e0 c015ff39 e5e92a00 
    <4>       ead2ae20 00000000 e891c800 00000000 dbfd29c0 c1c60000 c01599fe e5e92a00 
    <4>Call Trace: [<c015ff39>] [<c01599fe>] [<c0159e56>] [<c0159f59>] [<c015a039>] 

STACK TRACE FOR TASK: 0xe7ede000 (sendmail)

0 do_get_write_access+340 [0xc015fb48]
1 journal_get_write_access+52 [0xc015ff34]
2 ext3_do_update_inode+469 [0xc01599f9]
3 ext3_mark_iloc_dirty+29 [0xc0159e51]
4 ext3_mark_inode_dirty+36 [0xc0159f54]
5 ext3_dirty_inode+208 [0xc015a034]
6 __mark_inode_dirty+44 [0xc01464e4]
7 update_atime+70 [0xc0147a22]
8 do_generic_file_read+1105 [0xc012674d]
9 generic_file_read+124 [0xc0126a10]
10 sys_read+141 [0xc0133305]
11 system_call+44 [0xc0106e48]
ebx: 00000004   ecx: 0810dc38   edx: 00001000   esi: 0810a0b9
edi: 3e65d011   ebp: bfff9a5c   eax: 00000003   ds:  002b
es:  002b       eip: 401a7004   cs:  0023       eflags: 00000293
esp: bfff9a2c   ss:  002b


This looks like a bug that Andrew Morton posted a patch for recently:


> Under rare conditions (filesystem corruption, really) it is possible
> for ext3_dirty_inode() to require _two_ blocks for the transaction: one
> for the inode and one to update the superblock - to set
> EXT3_FEATURE_RO_COMPAT_LARGE_FILE.  This causes the filesystem to go
> BUG.
> 
> So reserve an additional block for that eventuality.


 fs/ext3/inode.c |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

--- 25/fs/ext3/inode.c~ext3-transaction-reserved-blocks	Sat Dec 14 18:28:21 2002
+++ 25-akpm/fs/ext3/inode.c	Sat Dec 14 18:28:21 2002
@@ -2698,7 +2698,7 @@ void ext3_dirty_inode(struct inode *inod
 	handle_t *handle;
 
 	lock_kernel();
-	handle = ext3_journal_start(inode, 1);
+	handle = ext3_journal_start(inode, 2);
 	if (IS_ERR(handle))
 		goto out;
 	if (current_handle &&

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/



_______________________________________________

Ext3-users@redhat.com
https://listman.redhat.com/mailman/listinfo/ext3-users

[Linux RAID]     [Kernel List]     [Red Hat Install]     [Video 4 Linux]     [Postgresql]     [Fedora]     [Fedora Legacy]     [Gimp]     [Yosemite News]     [Linux Software]