[OmniOS-discuss] Warning that partition is too large when mirroring identical disks in root pool
Willard Korfhage
omniti at familyk.org
Sun Feb 9 05:07:33 UTC 2014
Thanks for the explanation of the discrepancy.
The output of the fdisk -W commands is identical for both disks, as I
would expect, and the vtoc is identical on both disks, too.
I think I misinterpreted the intent of the message from fmthard. I was
concerned that it meant "the vtoc doesn't make sense, but I am copying
it to the disk, anyway," leaving me with a disk in a bad state. Instead
it appears to have been more of a "fixed that for you" message, and the
disk is fine, with all the dimensions matching on both disks. I will
continue with the mirroring.
On 2/8/2014 3:10 PM, Peter Tribble wrote:
> On Sat, Feb 8, 2014 at 6:21 AM, Willard Korfhage <omniti at familyk.org
> <mailto:omniti at familyk.org>> wrote:
>
> 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.
>
>
> Why do you think that? What the error you've given is saying is that
> the size of the Solaris partition on the new disk is smaller than the
> size of the Solaris partition on the original disk. That's all.
>
> 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.
>
>
> I can't see where that bug comes into play. The need to do a low-level
> format of a drive is extremely rare.
>
> I see these discrepancies fairly frequently when fdisk gets out of whack.
> Most commonly, because some drives have a diagnostic partition on them,
> but sometimes because it can't decide whether to start at cylinder 0 or 1.
> Or just because the drives were partitioned up on different OS versions.
>
> Compare:
>
> fdisk -W - /dev/rdsk/c2t0d0p0
> fdisk -W - /dev/rdsk/c2t1d0p0
>
> If the fdisk dimensions do actually match, then you could save
> out the fdisk table off the first disk and load it onto the second,
> something like:
>
> fdisk -W /tmp/fmap /dev/rdsk/c2t0d0p0
> fdisk -F /tmp/fmap /dev/rdsk/c2t1d0p0
>
> and then do the ptrtvtoc|fmthard step.
>
> If you look at the sizes reported, specifically:
>
> * 32130 sectors/cylinder
> * 60799 cylinders
> * 60797 accessible cylinders
>
> and
>
> * First Sector Last
> * Partition Tag Flags Sector Count Sector Mount Directory
> 0 2 00 32130 1953375480 1953407609
> 2 5 01 0 1953471870 1953471869
> 8 1 01 0 32130 32129
>
> then it's allocated slice 0 up to the end of the 60797 accessible
> cylinders, but slice 2 (which refers to the whole disk) is 64260
> sectors or 2 cylinders longer, filling out to the end of 60799.
> The second disk you have is reporting a size of 1953407610
> sectors, or 0-1953407609, or 32130*60797, so it's just picked
> up the accessible cylinders. The disks appear to be the same
> size, it's those 2 inaccessible cylinders that are confusing matters.
>
> If the fdisk dimensions are different (the second disk only appears
> to really be 60797 sectors) then it's still not a problem, as all you're
> interested in is slice 0, which is the right size. Simplest way to do
> that is to grep out the line in the prtvtoc output for partition 2, and
> fmthard will fill it in automatically at whatever size it thinks is
> correct.
>
>
> On 2/7/2014 11:54 AM, Warren Marts wrote:
>> This may be a genuine mismatch between the disks.
>>
>> 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.
>>
>> I was surprised, to say the least.
>>
>>
>> On Fri, Feb 7, 2014 at 10:14 AM, Willard Korfhage
>> <omniti at familyk.org <mailto:omniti at familyk.org>> wrote:
>>
>> 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.
>>
>> c2t0d0 is the disk with OmniOS
>> c2t1d0 is supposed to be its mirror
>>
>> To do the mirroring, following the directions in the wiki, I did
>>
>> root at s1:~# pfexec fdisk -B c2t1d0p0
>> root at s1:~# pfexec prtvtoc /dev/rdsk/c2t0d0s2 | pfexec fmthard
>> -s - /dev/rdsk/c2t1d0s2
>> fmthard: Partition 2 specifies the full disk and is not equal
>> full size of disk. The full disk capacity is 1953407610 sectors.
>> fmthard: Partition 2 specified as 1953471870 sectors starting
>> at 0
>> does not fit. The full disk contains 1953407610 sectors.
>> fmthard: New volume table of contents now in place.
>>
>>
>> At this point I stopped, and haven't done the mirror.
>>
>> For the disk with the install, format reports
>>
>> Current Disk = c2t0d0
>> <ATA-ST1000LM024HN-M-0001 cyl 60797 alt 2 hd 255 sec 126>
>> /pci at 0,0/pci8086,1c02 at 1f,2/disk at 0,0
>>
>> and further information is
>>
>> root at s1:~# pfexec prtvtoc /dev/rdsk/c2t0d0s2
>> * /dev/rdsk/c2t0d0s2 partition map
>> *
>> * Dimensions:
>> * 512 bytes/sector
>> * 126 sectors/track
>> * 255 tracks/cylinder
>> * 32130 sectors/cylinder
>> * 60799 cylinders
>> * 60797 accessible cylinders
>> *
>> * Flags:
>> * 1: unmountable
>> * 10: read-only
>> *
>> * Unallocated space:
>> * First Sector Last
>> * Sector Count Sector
>> * 0 32130 32129
>> *
>> * First Sector Last
>> * Partition Tag Flags Sector Count Sector Mount
>> Directory
>> 0 2 00 32130 1953375480 1953407609
>> 2 5 01 0 1953471870 1953471869
>> 8 1 01 0 32130 32129
>>
>> Any idea what is going on?
>>
>> 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
>> (https://www.illumos.org/issues/3610)
>>
>>
>>
>> _______________________________________________
>> OmniOS-discuss mailing list
>> OmniOS-discuss at lists.omniti.com
>> <mailto:OmniOS-discuss at lists.omniti.com>
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>>
>>
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> <mailto:OmniOS-discuss at lists.omniti.com>
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
>
>
> --
> -Peter Tribble
> http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140208/6d297368/attachment.html>
More information about the OmniOS-discuss
mailing list