From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 22 Apr 2010 11:55:54 -0600 To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net> From: "EBo" Message-ID: In-Reply-To: Subject: [9fans] corrupted update on 9vx Topicbox-Message-UUID: 0bb3ce48-ead6-11e9-9d60-3106f5b1d025 OK. I've been trying to track down the odd 9vx crash and discovered some other oddities and request some guidance in what might be causing the pull to become corrupted and installing entire blocks of nil's in updated files. Following details outlined in http://fixunix.com/plan9/501128-9fans-pull-9vx.html, I first tried to update the original plan9 distro, then moved to a new 9atom.iso. To get the pull to work I had to update the network and client db: # cp -a plan9/dist/replica/client/plan9.* root9atom/dist/replica/client/ # cp -a plan9/dist/replica/network root9atom/dist/replica/network Then I ran /usr/glenda/bin/rc/pull. At one point it seemed to work until I decided to recompile a couple of the commands in /sys/src/cmd and discovered that several of the source files had blocks of nil's in them. I wanted to see if the problem was systematic or more random, so I saved that root tree and reran the test. What I found is that the corruption happens very often and at seemingly random files and locations. I also wanted to check to see if these differences were consistent (like 4K blocks, etc). I found that the number of corrupted blocks, and their respective lengths, vary. I also found that they are not guaranteed to be multiples of 512. These tests were so far run on my AMD x86_64. I'll try rerunning these tests on an Intel based laptop to see if this is some weird x86_64'ism. I will also try the Tvx code compiled for i486 on both machines Does anyone have an idea what could be causing replica to behave so? Has anyone ever seen this behavior before? Thanks and best regards, EBo --