[lkml]   [1996]   [Jul]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Possible e2fs bug.
"Theodore Y. Ts'o" wrote:
> Date: Fri, 28 Jun 1996 20:57:06 +0800
> From: Bruce Murphy <>
> The process was stuck in a loop somewhere in Kernel-land I assume, as
> I couldn't terminate it. Ended up changing into single user mode to
> unmount and fsck the filesystem. Still had this damn rm running chewing
> up all idle CPU time.
> If you were able to unmount the filesystem while the rm was still
> running, then things were pretty confused indeed. The real question is
> wheather this was caused by (a) filesystem corruption, (b) a real kernel
> bug / race condition in the filesystem code, (c) a kernel bug somewhere
> else that trashed memory which the filesystem code depends on, or (d) a
> memory corruption bug.
> Unfortunately, it sounds like you weren't able to collect enough
> information to figure out which one of these cases is correct.

Filesystem was clean. (fsckly at least) and I couldn't actually
unmount it, I was forced to remount it read only. I wasn't expecting
that to work, but there you go.

I don't think there was any actual damage to the kernel filesystem
code itself, because no other operations were behaving strangely (a
parallel rm -r that finished successfully later and some other cleanup

Leaves it with real options being b and d. Didn't see any way I could
check (d) except to say that I haven't *seen* any of the other
symptoms of hardware memory problems, I'm not looking too hard, I'm
going to replace this box soon enough.

Just thought I might add my voice to anyone else's who was having
problems. Might prompt the maintainer of the e2fs stuff to have
another look at it sometime.

Packrat (BSc/BE;COSO;Wombat Implementor)
Nihil illegitemi carborvndvm.

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