Messages in this thread | | | Date | Tue, 21 Mar 2000 16:01:54 -0800 | From | Marc Merlin <> | Subject | Re: 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/
| |