Date: Sat, 19 Nov 2011 15:32:52 +0100 From: Marius Strobl <marius@alchemy.franken.de> To: Rory Arms <rorya+freebsd.org@TrueStep.com> Cc: freebsd-sparc64@freebsd.org Subject: Re: sparc64/162513: mpt(4), mptutil(8) reports variable, erroneous drive information Message-ID: <20111119143252.GB40335@alchemy.franken.de> In-Reply-To: <201111132330.pADNULCw089605@freefall.freebsd.org> References: <201111132330.pADNULCw089605@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Nov 13, 2011 at 11:30:21PM +0000, Rory Arms wrote: > The following reply was made to PR sparc64/162513; it has been noted by GNATS. > > From: Rory Arms <rorya+freebsd.org@TrueStep.com> > To: bug-followup@FreeBSD.org, rorya+freebsd.org@TrueStep.com > Cc: > Subject: Re: sparc64/162513: mpt(4), mptutil(8) reports variable, erroneous drive information > Date: Sun, 13 Nov 2011 12:06:44 -0500 > > Thanks for your usual prompt response, Marius. B) > > After I submitted this, it crossed my mind that it might be an endian = > issue. Well, I really bought that controller just so I could attach new = > SATA/SAS drives to my aging sun4u. So I don't need to use the RAID = > capabilities on it. > > You suggest using software RAID, which was what I was thinking of using = > anyway. So it's sofe to assume that using mpt(4) in a RAID-less = > configuration should not be a problem? I was thinking of using zfs or = Yes, the initiator side of mpt(4) is fine on sparc64, it's the target mode and mptutil(8) that still need fixes to work on big-endian. Especially for the former I simply lack the necessary hardware to fix it. > vinum to do RAID1 with 2 1 TB drives. I suppose it's possible that at = > some point I may hove those drives to amd64, so it would be nice if it = > would continue to work there w/o a dump & restore. As a recall zfs does = > write data in the endian order of the host that created the volume, but = > is smart enough to swap byte order as it reads the data from disk, when = > the disk is moved to a PC. But I assume there would be some kind of = > performance penalty for this. How about vinum and UFS2, would these = > require a restore of the data once moved to a PC? Yes, ZFS is endian agnostic AFAIK, but I don't know who that's implemented exactly or how much performance that costs. Hrm, this article suggests that ZFS will update the encoding of the metadata to be the native one of the hosts when writing it: http://www.informit.com/articles/article.aspx?p=712746 UFS{,2} on at least FreeBSD is tied to the endianess of the host and has no support for using the other one. AFAIK NetBSD has support for the latter but so far nobody has cared enough to port that support over. I don't know what's the state of GVINUM is, especially not on sparc64. GMIRROR works just fine on sparc64 though. > > Also at what size drive is OBP 3.10 going to have have a problem = > accessing or addressing a large drive? As I recall OBP had a 2 TB limit, = > so I assume there will be some kind of problem with drives above 2TB in = > size? How about the VTOC8 label, does it have similar limits? The VTOC8 label uses 16-bit fields for cylinders, heads and sectors. When maxing out heads and sectors at 255 this is sufficient for up to 2TB with 512 bytes sector size. The problem is that cam_calc_geometry(9) (I suspect this is based on an old Adaptec encoding) uses 255 heads but only 63 sectors in extended mode, which then is only sufficient for 500GB due to the maximum of 65536 cylinders with VTOC8. > > Regarding this endian issue with mpt(4)/mptutil(8) ioctl, I don't see a = > mention of it in the 8.2 release notes, hardware notes or errata = > documents. Wouldn't it make sense to add a note about this in there for = > the impending v9 release? There's tons of stuff in the base that only works on x86 or at least not on sparc64. What we'd need is an authoritative list of these things. I don't think that just saying that a specific X doesn't work on a certain platform will really improve the overall situation as then people may think that all the rest works. > I was actually about to upgrade to v9 to check = > for this problem, before I sent this. But decided to wait for the = > response first. I was just trying to find the corresponding release = > documents on the site for v9 but couldn't find them. At least, it used = > to be that you could see them on the site a few weeks before a release, = > but I can't find them now. > AFAIK release notes for 9.0 just haven't hit the tree, yet. Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111119143252.GB40335>