Date: Mon, 4 Aug 1997 19:38:22 -0700 (PDT) From: David Filo <filo@yahoo.com> To: Shimon@i-Connect.Net Cc: freebsd-scsi@freebsd.org Subject: Re: strange difference between DPT and Adaptec Message-ID: <199708050238.TAA28428@ns2.yahoo.com> In-Reply-To: <XFMail.970804183359.Shimon@i-Connect.Net> (message from Simon Shapiro on Mon, 04 Aug 1997 18:33:59 -0700 (PDT))
index | next in thread | previous in thread | raw e-mail
> > > 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)?home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708050238.TAA28428>