Subject: Re: duplicated inodes <[email-masked]>

From: "Michael Graff" <[email-masked]>

>does anyone else see a lot of duplicated inodes after during a lot of
>disk access? (a lot == building the world or something equally as large.)

Yes!  Or after untarring a large set of files, etc.

fsck loves to find DUPs for me when I do this.

I've mailed a report of this here, but I don't have enough info to nail it
down.  All are runngin fairly current kernels, and are either SCSI or IDE,
none are both.  They vary from 386sx to 486dx, no cyrix chips.

It seems to be somewhat usage-related -- the more full the disk gets, the
better the chance for a DUP, but this may just be because there are
more inodes in use, too.  *shrug*

--Michael

--
Michael Graff                 <[email-masked]>
1304 Florida #3               (515) 296-2735
Ames, IA  50014           PGP key on a server near YOU!

---

From: Jan-Hinrich Fessel <[email-masked]>

In message <[email-masked]>you write:
->does anyone else see a lot of duplicated inodes after during a lot of
->disk access? (a lot == building the world or something equally as large.)

Yes.  But only on my SCSI-drive(M2624SA) that did not do auto-remapping of bad
sectors.  The errors generated by this drive were put out by the kernel,
but apparently not or not always did the filesystem check for these,
because only around 10% of the kernel errors generated write failures.

What I desparetely needed then was some scsi-format and remp utility.

Gruesse
       Oskar

 ==============================================================================
 					Tragbar ist, was nicht herunterfaellt.
						    [email-masked]
 ==============================================================================

---

From: James Dolter <[email-masked]>

>>>>> "downsj" == jason downs <[email-masked]> writes:

    downsj> does anyone else see a lot of duplicated inodes after
    downsj> during a lot of disk access? (a lot == building the world
    downsj> or something equally as large.)

I have also been experiencing the same problems:

   1. System built around 1st week of Sept.
   2. 486DX external cache off

   The problem has surfaced both on a EDSI and SCSI drives both
   having at least 20% free space.... 

   A complete make && make install at /usr/src or trying to build
   gcc-2.6.x seems to be sufficient to cause corruption.

   Haven't had time to track it down any further...

-- Jim Dolter
   <[email-masked]>

---

From: Duncan McEwan <[email-masked]>

[This message started off life as a followup to the "fsck finds DUPs" thread,
but I wanted to check a few things out before sending it.  That thread now
seems to have died off, but this one has just started, so I'll add my 2c here
instead ...]

> disk access? (a lot == building the world or something equally as large.)

I have been experiencing problems like these since the begining of this year,
when we got some new 486 based pc's for a lab.

Initially I was convinced that the problem must lie with my hardware, since no
one else on the mailing lists was reporting similar problems.  Now, after some
further testing, and this recent flurry of similar sounding reports, I'm not so
sure.

The problem I am seeing is that a disk sector from one part of the disk
occasionally ends up getting written to an incorrect location.  I've used fsdb
(which doesn't come with NetBSD, but which I compiled from our 4.4 sources) to
confirm this.

If the overwritten sector is a file data block you might never notice a
problem, since fsck doesn't see anything wrong.  Alternatively, if the affected
file was a binary, it might mysteriously start dumping core whereas a freshly
compiled binary works fine.  Or you might see compilations failing due to
syntax errors, and on investigation find a C source file with part of some
other random file (always a multiple of 512 bytes) imbedded in the middle.
I've experienced all of the above :-(

But if both affected sectors contained inodes, fsck will report many DUP
blocks.  The pattern of duplicates I see seems to confirm the theory that they
were caused by one sector of inodes overwriting another.

The problem mostly seems to occur during relatively sustained and intensive
disk i/o, such as when doing a "make build".  But recently, in order to get
more information, I wrote a simple perl script that kept doing random cp's,
cmp's and rm's until an error was detected.  This script seems to relatively
reliably trigger the problem after a few hours of running.  Curiously however,
it never seems to trigger the inode->inode type of error ... it's always a
datablock->datablock error, whereas the "make build" causes either equally
often...

Some other possibly relevant details follow:

My script copies files and checks the results using the perl "system" function
with a command string like "(cp ...; if cmp ...; then ... ) &".  The "&" causes
some degree of multitasking.  When I ran it in single user mode, with no
backgrounding (to minimise "concurrent" disk access) it ran for ~ 12 hours
without error.

I've been having these problems with versions of netbsd-current from both
before and after the new filesystem code was integrated.  I've now run 'fsck
-c2' on all my filesystems, and the problem still occurs.

My hardware is a 486DX2/66 with 16MB of memory, a micronics mpower-4
motherboard with on-board localbus mach32 video and an on-board localbus ide
controller, 2 340MB conner cp30344 ide drives.  The problem also occurs on a pc
with the same motherboard but a 486/33, 8MB of memory and a single 240MB conner
drive.  And I've also recently discovered that it occurs on a 40MHz 386 with a
non-localbus isa no-name ide controller.

Turning off caching (both internal and external) and a bios option called
"fast ide" didn't make any difference.

Having got to the stage where I could reasonably reliably reproduce the problem
under NetBSD, I installed OS/2 on the 486/33, and ran a slightly modified (to
cope with unix - os/2 differences) perl script on it.  It ran happily over a
weekend without error.

I'm still not 100% convinced that the problems I am seeing are the same as are
being reported here, since up til now other reports have only concerned
duplicate block errors ... no-one else seems to be seeing more general file
corruption.

Duncan