sparc64/162513: mpt(4), mptutil(8) reports variable, erroneous drive information

Rory Arms rorya+freebsd.org at TrueStep.com
Sun Nov 13 23:30:22 UTC 2011


The following reply was made to PR sparc64/162513; it has been noted by GNATS.

From: Rory Arms <rorya+freebsd.org at TrueStep.com>
To: bug-followup at FreeBSD.org, rorya+freebsd.org at 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 =
 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?
 
 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?
 
 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? 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.
 


More information about the freebsd-sparc64 mailing list