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))
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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)?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708050238.TAA28428>