On 5/3/12 10:09 AM, Jack Schwartz wrote:
Hi Drew.
partition_edit_screen.py: Just curious: Do you need to do the same
thing that you do on 167, in GPTPartEditScreen/_show() at line 365?
The reason that we have to do this with VTOC is because when the user
selects "use the entire disk", we can't set Disk.whole_disk to True. We
have to manually carve up the disk to have slice 0 (what's given to
zpool create), slice 2 (backup) and slice 8 (x86 boot slice). Because
of this, we *must* set Disk.whole_disk to False so we don't try to
create the root pool in the wrong way (zpool create <vdev> has always
put an EFI label on the disk and up until 13/14 we couldn't boot from
EFI labelled disks).
Since Disk.whole_disk ends up being False, we incorrectly enter the
partition edit screen which was CR 7164145.
GPT, OTOH, *can* use the concept of Disk.whole_disk. The UEFI project
put back a shiny new flag to zpool create (-B) which, when added,
creates all the necessary boot partitions for us. When the user selects
"use whole disk", the target controller sees a GPT label and keeps the
attribute set to True. On VTOC, it switches it to False for the reasons
explained above.
I know the notion of "whole disk" is messy. If you have questions, let
me know.
Thanks,
Jack
P.S. Also, FWIW, I found two settings of USE_WHOLE_DISK in
gpt_partitions.py at lines 61 and 68. Not sure if you want to fix it
at this time. I just filed a P5 bug: 7166190
I grabbed it and removed the first entry (so existing behavior didn't
change). Thanks for spotting this one.
-Drew
On 05/ 2/12 02:43 PM, Drew Fisher wrote:
I need send this out for a second round of code review. I just tried
this code on x86 and it crashes out due to the changes in disk_window.py
https://cr.opensolaris.org/action/browse/caiman/drewfish/7091644_2/
(I think the number of people editing slices on x86 is
extraordinarily small, otherwise we would have seen a bug on this).
The change in partition_edit_screen also stems from slice editing on
x86. If we get to editing the slice, we have a partition/slice
relationship and we have no information about a disk. The gettattr
returns the default of False if the object in question (a disk)
doesn't have a 'use_whole_segment' attribute. It's exactly like
dict.get(key, [default]).
ti_target_utils.py is completely unchanged.
Thanks!
-Drew
On 5/1/12 6:31 AM, Drew Fisher wrote:
Good morning!
Could I please get a code review for the following CR:
7091644 <http://monaco.us.oracle.com/detail.jsf?cr=7091644> Using F5
during slice selection often doesn't do anything
https://cr.opensolaris.org/action/browse/caiman/drewfish/7091644/webrev/
There are actually 3 cases where F5 simply doesn't work.
1: On a "blank" disk to simply move which slice rpool will occupy
2: On a disk that has had some limited editing done to it (via
format), a user is not able to move rpool to a presized slice. e.g.
if my disk was carved up with a 50gb s0 and a 50gb s1, TI will start
out with s0 marked as usable by rpool. No matter what the user did,
they could never select s1
3: Active / Imported pools will not cycle correctly. The cycle
pattern ends up being: Active Pool Name -> Unused -> rpool ->
Unused -> rpool .... Using F5, the user can not ever return back to
the Active Pool. This is easily remedied by pressing F7 to reset
the entire screen.
The fix for this CR addresses cases 1 and 2 above. For case 3, I'm
placing less priority on this issue as the circumstances required to
trip over it are that the user must import a zpool and want to reuse
that imported pool's slice for the rpool zpool. If people feel
differently, we can either file a CR to specifically track that issue.
Thanks!
-Drew
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
