<div dir="ltr">On Sat, Feb 8, 2014 at 6:21 AM, Willard Korfhage <span dir="ltr"><<a href="mailto:omniti@familyk.org" target="_blank">omniti@familyk.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
That could happen, depending on how many bad blocks the disk has,
but in this case, the numbers it reports, the numbers it says are
inconsistent, are from the original OmniOS install. I am surprised
that the original install would generate an inconsistent partition
arrangement.<br></div></blockquote><div><br></div><div>Why do you think that? What the error you've given is saying is that<br></div><div>the size of the Solaris partition on the new disk is smaller than the<br>size of the Solaris partition on the original disk. That's all.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
Now if I could just figure out how to format the disk, I could try
starting from scratch. Given the Illumos bug, I suppose I'll have to
pull it and format it on another machine.<br></div></blockquote><div><br></div><div>I can't see where that bug comes into play. The need to do a low-level<br>format of a drive is extremely rare.<br><br></div><div>
I see these discrepancies fairly frequently when fdisk gets out of whack.<br></div><div>Most commonly, because some drives have a diagnostic partition on them,<br></div><div>but sometimes because it can't decide whether to start at cylinder 0 or 1.<br>
</div><div>Or just because the drives were partitioned up on different OS versions.<br></div><div><br></div><div>Compare:<br><br></div><div>fdisk -W - /dev/rdsk/c2t0d0p0<br>fdisk -W - /dev/rdsk/c2t1d0p0<br><br></div>If the fdisk dimensions do actually match, then you could save<br>
out the fdisk table off the first disk and load it onto the second,<br>something like:<br><br>fdisk -W /tmp/fmap /dev/rdsk/c2t0d0p0<br>fdisk -F /tmp/fmap /dev/rdsk/c2t1d0p0<br><br></div><div class="gmail_quote">and then do the ptrtvtoc|fmthard step.<br>
</div><div class="gmail_quote"><br></div><div class="gmail_quote"><div>If you look at the sizes reported, specifically:<br><br>* 32130 sectors/cylinder<br>
* 60799 cylinders<br>
* 60797 accessible cylinders<br><br>and</div><div><br>* First Sector Last<br>
* Partition Tag Flags Sector Count Sector Mount
Directory<br>
0 2 00 32130 1953375480 1953407609<br>
2 5 01 0 1953471870 1953471869<br>
8 1 01 0 32130 32129<br><br></div><div>then it's allocated slice 0 up to the end of the 60797 accessible<br>cylinders, but slice 2 (which refers to the whole disk) is 64260<br>
</div><div>sectors or 2 cylinders longer, filling out to the end of 60799.<br></div><div>The second disk you have is reporting a size of 1953407610<br></div><div>sectors, or 0-1953407609, or 32130*60797, so it's just picked<br>
</div><div>up the accessible cylinders. The disks appear to be the same<br></div><div>size, it's those 2 inaccessible cylinders that are confusing matters.<br></div><div><br>If the fdisk dimensions are different (the second disk only appears<br>
</div><div>to really be 60797 sectors) then it's still not a problem, as all you're<br>interested in is slice 0, which is the right size. Simplest way to do<br></div><div>that is to grep out the line in the prtvtoc output for partition 2, and<br>
fmthard will fill it in automatically at whatever size it thinks is correct.<br><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>On 2/7/2014 11:54 AM, Warren Marts
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">This may be a genuine mismatch between the disks.
<div><br>
</div>
<div>A few weeks ago I was trying to image between two
apparently identical Western Digital RE2 400GB drives. They
were produced on the same day and their serial numbers were
only ~200 apart, but the disk utility reported block counts
that differed by about 20,000 (10 MB) and neither count
matched the one on the disk label.</div>
<div><br>
</div>
<div>I was surprised, to say the least. </div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Feb 7, 2014 at 10:14 AM,
Willard Korfhage <span dir="ltr"><<a href="mailto:omniti@familyk.org" target="_blank">omniti@familyk.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I just
installed OmniOS r151008j last night, and today I wanted to
mirror rpool, but have a warning about the disk size. I have
2 Seagate 1TB disks (model ST1000LM024HN), and my OmniOS
install is on one of them. I told the install to use the
whole disk. Some version of OpenIndiana was previously
installed on the disk. The install went without any problem.<br>
<br>
c2t0d0 is the disk with OmniOS<br>
c2t1d0 is supposed to be its mirror<br>
<br>
To do the mirroring, following the directions in the wiki, I
did<br>
<br>
root@s1:~# pfexec fdisk -B c2t1d0p0<br>
root@s1:~# pfexec prtvtoc /dev/rdsk/c2t0d0s2 | pfexec
fmthard -s - /dev/rdsk/c2t1d0s2<br>
fmthard: Partition 2 specifies the full disk and is not
equal<br>
full size of disk. The full disk capacity is 1953407610
sectors.<br>
fmthard: Partition 2 specified as 1953471870 sectors
starting at 0<br>
does not fit. The full disk contains 1953407610 sectors.<br>
fmthard: New volume table of contents now in place.<div class=""><br>
<br>
At this point I stopped, and haven't done the mirror.<br>
<br></div>
For the disk with the install, format reports<br>
<br>
Current Disk = c2t0d0<br>
<ATA-ST1000LM024HN-M-0001 cyl 60797 alt 2 hd 255 sec
126><br>
/pci@0,0/pci8086,1c02@1f,2/disk@0,0<br>
<br>
and further information is<br>
<br>
root@s1:~# pfexec prtvtoc /dev/rdsk/c2t0d0s2<br>
* /dev/rdsk/c2t0d0s2 partition map<br>
*<br>
* Dimensions:<br>
* 512 bytes/sector<br>
* 126 sectors/track<br>
* 255 tracks/cylinder<br>
* 32130 sectors/cylinder<br>
* 60799 cylinders<br>
* 60797 accessible cylinders<br>
*<br>
* Flags:<br>
* 1: unmountable<br>
* 10: read-only<br>
*<br>
* Unallocated space:<br>
* First Sector Last<br>
* Sector Count Sector<br>
* 0 32130 32129<br>
*<br>
* First Sector Last<br>
* Partition Tag Flags Sector Count Sector Mount
Directory<br>
0 2 00 32130 1953375480 1953407609<br>
2 5 01 0 1953471870 1953471869<br>
8 1 01 0 32130 32129<br>
<br>
Any idea what is going on?<br>
<br>
I tried to format the disk without the install (c2t1d0),
just to start with a completely fresh disk, but it doesn't
work. This appears to be a long-standing (11-month old)
Illumos bug (<a href="https://www.illumos.org/issues/3610" target="_blank">https://www.illumos.org/issues/3610</a>)<div class=""><br>
<br>
<br>
_______________________________________________<br>
OmniOS-discuss mailing list<br>
<a href="mailto:OmniOS-discuss@lists.omniti.com" target="_blank">OmniOS-discuss@lists.omniti.com</a><br>
<a href="http://lists.omniti.com/mailman/listinfo/omnios-discuss" target="_blank">http://lists.omniti.com/mailman/listinfo/omnios-discuss</a><br>
</div></blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
<br>_______________________________________________<br>
OmniOS-discuss mailing list<br>
<a href="mailto:OmniOS-discuss@lists.omniti.com">OmniOS-discuss@lists.omniti.com</a><br>
<a href="http://lists.omniti.com/mailman/listinfo/omnios-discuss" target="_blank">http://lists.omniti.com/mailman/listinfo/omnios-discuss</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>-Peter Tribble<br><a href="http://www.petertribble.co.uk/">http://www.petertribble.co.uk/</a> - <a href="http://ptribble.blogspot.com/">http://ptribble.blogspot.com/</a>
</div></div>