sparc64/162513: mpt(4), mptutil(8) reports variable,
erroneous drive information
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
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