Yep, well said, understood, point taken, I hear you, you're
preaching to the choir. Have faith in Santa.

A few comments:

1. I need more info on the x86 install issue. I haven't seen this
problem myself.

2. We don't use slice2 for anything and its not recommended.

3. The SMI disk is a long-standing boot requirement. We're
working on it.

4. Both the s10 and s11 installer can create a mirrored root pool
so you don't have to do this manually.

If you do have do this manually in the S11 release, you can use
this shortcut to slap on a new label but it does no error checking
so make sure you have the right disk:

# format -L vtoc -d c1t0d0

Unfortunately, this applies the default partition table, which
might be a 129MB slice 0, so you still have to do the other 17 steps to
create one large slice 0. I filed an RFE to do something like this:

# format -L vtoc -a(ll) s0 c1t0d0

5. The overlapping partition error on x86 systems is a bug (unless they
really are overlapping) and you can override it by using the -f option.

Thanks,

Cindy

On 12/16/11 09:44, Gregg Wonderly wrote:
The issue is really quite simple. The solaris install, on x86 at least,
chooses to use slice-0 for the root partition. That slice is not created
by a default format/fdisk, and so we have the web strewn with

prtvtoc path/to/old/slice2 | fmthard -s - path/to/new/slice2

As a way to cause the two commands to "access" the entire disk. If you
have to use dissimilar sized disks because 1) that's the only media you
have, or 2) you want to increase the size of your root pool, then all we
end up with, is an error message about overlapping partitions and no
ability to make progress.

If I then use dd if=/dev/zero to erase the front of the disk, and the
fire up format, select fdisk, say yes to create solaris2 partitioning,
and then use partition to add a slice 0, I will have problems getting
the whole disk in play.

So, the end result, is that I have to jump through hoops, when in the
end, I'd really like to just add the whole disk, every time. If I say

zpool attach rpool c8t0d0s0 c12d1

I really do mean the whole disk, and I'm not sure why it can't "just
happen". Failing to type a "slice" reference, is no worse of a 'typo'
than typing 's2' by accident, because that's what I've been typing with
all the other commands to try and get the disk partitioned.

I just really think there's not a lot of value in all of this,
especially with ZFS, where we can, in fact add more disks/vdevs to a
keep expanding space, and extremely rarely is that going to be done, for
the root pool, with fractions of disks.

The use of SMI and absolute refusal to use EFI partitioning plus all of
this just stacks up to a pretty large barrier to "simple" and/or "easy"
administration.

I'm very nervous when I have a simplex filesystem setting there, and
when a disk has "died", I'm doubly nervous that the other half is going
to fall over.

I'm not trying to be hard nosed about this, I'm just trying to share my
angst and frustration with the details that drove me in that direction.

Gregg Wonderly

On 12/16/2011 2:56 AM, Andrew Gabriel wrote:
On 12/16/11 07:27 AM, Gregg Wonderly wrote:
Cindy, will it ever be possible to just have attach mirror the
surfaces, including the partition tables? I spent an hour today
trying to get a new mirror on my root pool. There was a 250GB disk
that failed. I only had a 1.5TB handy as a replacement. prtvtoc ... |
fmthard does not work in this case

Can you be more specific why it fails?
I have seen a couple of cases, and I'm wondering if you're hitting the
same thing.
Can you post the prtvtoc output of your original disk please?

and so you have to do the partitioning by hand, which is just silly
to fight with anyway.

Gregg


_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to