lkml.org 
[lkml]   [2000]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: apparent ext3 oops
On mar, mar 21, 2000 at 03:09:15 +0000, Stephen C. Tweedie wrote:
> > There was debugging output that said:
> > assertion failure in sync_old_buffers() at buffer.c linue 1956:
> > "!bh->b_transaction", which is consistent with the EIP info.
>
> This is a debugging trap which basically means that the background bdflush
> sweep found a buffer on the kernel's dirty buffer list which had an active
> transaction against it (which means that the buffer should have been on
> the protected, journal list).
>
> Was there anything odd prior to this happening? Anything in the logs?

I should probably have mentionned those:
Mar 13 06:33:58 pao kernel: EXT3-fs error (device rd(48,7)): ext3_get_inode_loc:
bad inode number: 0
Mar 13 06:33:58 pao kernel: find_fh_dentry: 30:07/81921 dir/0 not found!
Mar 13 06:33:58 pao kernel: fh_verify: not found gumdrop.su.varesearch.com: exp
30:07/81921 file (30:07/81921 dir 0) coookie 0xfeebbaca, generation 0x0

However those aren't corruption errors, they were due to a knfs problem
where knfs would try to fetch inode 0 from disk. HJ added some debug info in
knfs and we found the client that was holding the bad filehandle

> The fact that the fs was remounted with errors suggests that something
> else had gone wrong before this (the oops above would not cause the fs
> to be marked with errors).

Ok: my logs say
(other partitions being mounted)
Mar 17 16:51:57 pao kernel: JFS DEBUG: (journal.c, 528): journal_init_inode: jou
rnal df51a7e0: inode 30:07/532, size 40960000, bits 12, blksize 4096
Mar 17 16:51:57 pao kernel: JFS DEBUG: (recovery.c, 411): journal_recover: JFS:
recovery, exit status 0, recovered transactions 102076 to 102088
Mar 17 16:51:57 pao kernel: EXT3-fs: recovery complete.
Mar 17 16:51:57 pao kernel: EXT3-fs warning: mounting fs with errors, running e2
fsck is recommended

Is is correct to assume that the mounting fs with errors message applies to the mount entry immediately up in the log? If so, I don't get it because e2fsck
came out clean:
pao:~# e2fsck -fy /dev/rd/c0d0p7
e2fsck 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/rd/c0d0p7: 207188/5406720 files (10.5% non-contiguous), 12553414/21595368 b
locks
pao:~#

> Finally, are you running anything that touches buffers directly on this
> disk,

No software raid. I don't know about other things that could touch the
buffers directly.

> or were you doing any heavy delete operations? I have just found a

One NFS client may have had, I can't say...

> locking bug: journal_forget() does not take the journal lock, so that
> could well explain the problem if you were deleting data at the time.
>
> I'll release a 0.0.2d for 2.2.15 with that fix in place once I've stress
> tested things a bit more thoroughly.

I'll have a look at it when it comes out.

Marc
--
Microsoft is to software what McDonalds is to gourmet cooking

Home page: http://marc.merlins.org/ (friendly to non IE browsers)
Finger marc_f@merlins.org for PGP key and other contact information

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.376 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site