lkml.org 
[lkml]   [1997]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Possible bug in sxt2 filesystem or drivers.
Hi,

On Mon, 20 Jan 1997 08:30:00 -0800 (PST), Leslie Donaldson
<leslied@std.teradyne.com> said:

> I ran across this bug this weekend and I am trying to reproduce it, but I
> haven't been able to yet. (I think it is a race condition.

> commands
> while true do
> mkdir a
> mkdir a/b
...
> rm -r a
> end
> Second process
> while true do
> ls -lag a/b/c
> end

> As this stress test was running the ls command reported getting a
> block that was help there. Then ext2-fs dumped a whole bunch of
> filesystem errors. These were the standard type(attempting to go to
> a sector that dosen't exist.) This appears to be a race condition
> involving locks (???????) The kernel was 2.1.21 on slackware from
> October(slackware came with 2.0.0)

Hmm. I thought this might be a directory ext2fs bug, but I've been
checking the code and I can't see anything obviously broken in the
directory handling with respect to concurrent ls and rmdir. I thought
it might be a problem if a directory gets cut back to zero length
during a block read, but we appear to handle that.

Without a bit more information, it's hard to get much further with
this. Do you have the actual syslog output handy? That would help a
lot in pinpointing a kernel bug. It might also show up another
possible cause --- a *lot* of these types of problem turn out to be
hardware related (in excess of 99% of this type of problem is either
hardware or a driver fault). However, if it is an ext2fs problem, the
syslog output would help a great deal.

Cheers,
Stephen.

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