Subject: (absence of) duplicated inodes

From: jason downs <[email-masked]>

following mycroft's advice, i turned off doreallocblks. i then built
X11, which usually causes a couple of FS problems. they didn't happen,
this time.

maybe someone should investigate this further?

*** /sys/kern/vfs_cluster.c.orig	Wed Aug 24 14:37:44 1994
--- /sys/kern/vfs_cluster.c	Sat Sep 17 15:22:21 1994
***************
*** 48,58 ****
  #ifdef DEBUG
  #include <vm/vm.h>
  #include <sys/sysctl.h>
! int doreallocblks = 1;
  struct ctldebug debug13 = { "doreallocblks", &doreallocblks };
  #else
  /* XXX for cluster_write */
! #define doreallocblks 1
  #endif
  
  /*
--- 48,58 ----
  #ifdef DEBUG
  #include <vm/vm.h>
  #include <sys/sysctl.h>
! int doreallocblks = 0;
  struct ctldebug debug13 = { "doreallocblks", &doreallocblks };
  #else
  /* XXX for cluster_write */
! #define doreallocblks 0
  #endif
  
  /*
--
                    ----------------------------------------
-------------------// jason downs // [email-masked] //------------------
                   ----------------------------------------      JD105
		  http://www.CSOS.ORST.EDU/downsj/index.html
	       I remember the day when Sun made decent computers.

---

From: Paul Southworth <[email-masked]>

> X11, which usually causes a couple of FS problems. they didn't happen,

Good!  Hopefully this will help cure my system as well.  Can anyone offer 
me a thumbnail description of what doreallocblks does and why I would 
want it turned on or off?

Thanks.

--Paul

---

From: "Charles M. Hannum" <[email-masked]>

Can anyone offer me a thumbnail description of what doreallocblks
   does [...]

If `doreallocblks' is non-zero, the kernel will try to relocate data
blocks to improve clustering performance.  Unfortunately, this code is
known to be somewhat unstable, and should probably be turned off by
default for now.

---

From: Duncan McEwan <[email-masked]>

> X11, which usually causes a couple of FS problems. they didn't happen,

Unfortunately I can't report the same good results.  I edited vfs_cluster.c to
turn off doreallocblks, built (using sources supped yesterday) and booted a new
kernel and then ran a perl script I wrote that previously relatively reliably
triggered FS corruption.  It still does... :-(

I've enclosed a copy of the script on the off-chance that someone else who has
been having this problem might like to try running it.  Note: I accept no
responsibility for any damage to file systems that this script causes!

Duncan

--- cut here ---

#!/usr/local/bin/perl
#
# Running this script on my netbsd 1.0-beta system, on an i386 eventually (it
# varies, but usually in less than half an hour) results in a newly copied
# file and the file it was copied from being different (as detected by cmp),
# indicating some form of file system corruption has occured.
#

srand;

#
# None of the directories in the following list can have subdirectories,
# otherwise the wildcard expansion messes up.
#
@srclist = (`ls /usr/bin/* /usr/sbin/* /usr/X386/bin/*`);

#
# Create the following directories.  If you want to give your disk a really
# good work out, you could create them in different parts of the file system,
# increasing the chance that they will end up in different cylinder groups,
# thus causing more head movement...
#
@dstdirs = ("test1", "test2", "test3");

for (;;) {

        $sleeptime = int (rand (3));
        $delaytime = int (rand (25)) + 1;

        #
        # pick random src
        #
        $fileindex = int (rand ($#srclist + 1));
        chop($srcfile = $srclist[$fileindex]);
        ($dir, $file) = $srcfile =~ m?(/.*)/([^/]+)?;

        #
        # pick random destination
        #
        $dstindex = int (rand ($#dstdirs + 1));
        $randext  = int(rand(32767));
        $dstfile  = "$dstdirs[$dstindex]/$file.$randext";

        $cmd = "(cp $srcfile $dstfile; " .
                "if cmp $srcfile $dstfile; then " .
                    "sleep $delaytime; rm $dstfile; " .
                "else " .
                    "echo \007Done!!!; kill $$;" .
                "fi) &";

        system($cmd);

        print "cp $srcfile -> $dstfile\n";
        sleep($sleeptime);
}

---

From: "Charles M. Hannum" <[email-masked]>

Could you describe your hardware *exactly*?  What brand motherboard,
disks, disk controller?  I *know* there are IDE drives with buggy
firmware that will cause random reordering of data, that manage to get
to market because they seem to work with DOS just fine.  (Maybe you
already did and I missed it; I tend to not pay much attention to the
mailing lists these days.)

For the record, I've never seen problems with `doreallocblks' or
`doasyncfree' on any machines I have, but it was suggested to me a
while back by Kirk that there `might' be a problem with that code.
I've never heard any more about it from him, and I *have* asked.