From owner-freebsd-scsi Mon Aug 4 19:39:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA13679 for freebsd-scsi-outgoing; Mon, 4 Aug 1997 19:39:25 -0700 (PDT) Received: from ns2.yahoo.com (ns2.yahoo.com [205.216.162.20]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA13674 for ; Mon, 4 Aug 1997 19:39:24 -0700 (PDT) Received: (from filo@localhost) by ns2.yahoo.com (8.8.5/8.6.12) id TAA28428; Mon, 4 Aug 1997 19:38:22 -0700 (PDT) Date: Mon, 4 Aug 1997 19:38:22 -0700 (PDT) Message-Id: <199708050238.TAA28428@ns2.yahoo.com> From: David Filo To: Shimon@i-Connect.Net CC: freebsd-scsi@freebsd.org In-reply-to: (message from Simon Shapiro on Mon, 04 Aug 1997 18:33:59 -0700 (PDT)) Subject: Re: strange difference between DPT and Adaptec Reply-To: filo@yahoo.com Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > This problem is a bit strange. I've got a disk (fujitsu narrow, > > running 2.2 with 1.1.10 DPT code) that seems to work just fine with an > > Adaptec 2940. If I connect the drive (just by itself) to the DPT card > > it comes up fine - but there is one particular directory that if I try > > to "ls" in, the machine panics with "bad dir ino at offfset 0: mangled > > entry". I found this because fsck would fail on bus error (on this > > paricular directory) under DPT but work fine with the 2940. > > > > > I dd'ed the entire drive onto another and that copy does not exhibit > > this behavior. > > You probably did the dd undr the DPT. Right? > Actually the dd was using the Adaptec, which I guess was kind of stupid. I did the same using the DPT and the dd'ed copy had the same problem - mangled directory causing a panic. And the new copy also fails with the 2940, which makes sense. So on the original disk there is some data that the 2940 can read but the DPT cannot. > > Joking aside, the DPT firmware, sometimes reserves one block at the > start of the disk for its own purposes, and slips all LBAs by one. > > The theory is that it does it on ALL RAID devices and on the lowest > target on the lowest bus on the first controller. The drive in question was not in a raid array, but was target 0 on bus 0 (only one controller is used). BTW, the problem persists if original drive is moved to target 1 bus 0, with a boot disk at target 0. > > BTW, this sector is what allows the DPT firmware to know what RAID arrays > are where and how. If you are brave, disconnect a large array, shuffle > the drive (after changing target IDs and try to boot. run the dptmgr > and look at the confusion. > I've noticed this when trying to build arrays from scratch using drives that used to be in arrays. I learned that you need to delete the arrays with dptmgr before rearranging things. > > Moral: When moving disks form HBA to HBA, low-level format them. > Okay, but i still don't understand what's going on. When we buy drives we don't low-level format them. Just plop them in and run fdisk, disklabel, and newfs. No problems to date. Will low-level format reserve space in the DPT case? Does extra space need to be reserved with fdisk for the DPT? Does this mean you can't clone a machine by simply dd'ing the disk if the destination adapter (say DPT) was not used to build the original disk (say 2940)?