Alok,
Good write up, comments below :
On 01/13/11 08:32 PM, Alok Aggarwal wrote:
This email is required reading for: Darren, Dermot, Matt, Niall,
Karen, Jean and Drew. Optional for others.
The following changes/clarifications are proposed to
the current TI/TD design.
General flow of an app:
----------------------
The app or the target controller will call into TD to do the device
discovery. TD populates everything it finds in the Target.DISCOVERED
tree in the DOC.
When the app intends to make changes to the devices/layout of those
devices, it/target controller will make a copy of Target.DISCOVERED
and call it Target.DESIRED. The controller will then call
partition.add_partition/delete_partition,
slice.add_slice/delete_slice, etc on behalf of the app. These calls in
turn will trigger validation of the requested change using Shadow
Lists. If the requested operation yields no validation errors, the
change is carried through to Target.DESIRED. If any validation errors
occur, they will be stored in the error service and at the same time
the change
will still be carried through to Target.DESIRED. A complete list
of the calls to make to change Target.DESIRED is below[1].
So if a validation error occurs, Target class will always carry out the
action and simply update Error service that it thinks there might be a
problem. In the case say the app/target_controller attempts to add a 5th
primary partition, we know that this is invalid, yet Target class will
still add this and report via error service that there was an error,
then it's up to the app/target_controller to reverse this action by
removing the 5th primary ?
I don't totally agree with this, as this means logic for an invalid 5th
primary partition will exist in more that one location, both the Target
class and the app/target_controller will have to know that it is not
valid. Would it not make more sense to have a known set of "hard" errors
and these not be carried through. The app/target_controller will then
only need to know if the error was "hard" or "soft", which can be
notified via agreed pre-defined contents of the error messages.
The app/target controller decides whether the reported errors are
"soft" (interim state change is okay) or "hard" (interim state is a
hard failure). After the app/target controller has made all the
necessary changes to Target.DESIRED, it calls ti.final_validation()
which validates Target.DESIRED completely and stores any errors thus
found in the error service.
The api/target controller has to then go through the process of
ensuring that the errors in the error service are appropriately addressed
and final_validation is successful prior to calling TI.
Once Target.DESIRED is fully valid, the app/target controller calls TI
to lay out the targets as indicated in Target.DESIRED.
Target Validation
-----------------
Target Validation will be performed via the use of Shadow Lists
on the backend. The following is a list of all the validation
checks that will be made for the respective target entities
not counting the checks specific for GPT.
Partition
- Only one Solaris2 partition on a given disk should exist
- A maximum of 4 primary partitions can be present
- A maximum of 1 extended partition and at most 32 partitions
within that (one Solaris2 partition) can be present
32 Logicals... one Solaris2 should exist for all 36 possible partitions,
e.g. if Solaris2 specified on one of the Primary's then it's not
possible to have Solaris2 on any of the Logicals either.
- Partitions should not overlap
- Partitions should not be too small for a given architecture
- Solaris2 partition must be <2TB for VTOC
- FAT32 partition must be <4GB
- Extended partition must greater than a certain size (to
account for 63 reserved sectors, etc)
- A partition must not be in-use for something else (eg: part
of a zpool)
Slice
- Number of slices must not exceed MAX_NSLICES
- Slice number must be MAX_NSLICES-1
- Slice size must be less than the size of a disk
- S2 must be the backup slice
- S1 must be swap slice (is this really even needed?)
- Slices should not overlap
- A slice must not be in-use for something else (eg: part of
a zpool)
Zpool
- Pool name must be unique
- Pool should not have vdevs that are part of another pool
- Pool mountpoint, if specified, should be unique
Where is vdev validation done ? e.g.Number of vdevs in a pool required
by redundancy type, e.g. if a mirror then at least two vdev's required,
if raidz2, at least three are required.
Or validation that a vdev which exists in one redundancy type cannot be
part of another redundancy.
cheers
Matt
Size
----
TD/TI will internally always operate on sectors (base 2).
A 'Size' class will be provided to assist in converting
the size in sectors to bytes/KB/MB/GB/TB.
The classmethods supported by this class are:
def bytes(cls, sectors, cylsize=512)
def KB(cls, sectors, cylsize=512)
def MB(cls, sectors, cylsize=512)
def GB(cls, sectors, cylsize=512)
def TB(cls, sectors, cylsize=512)
def sectors(cls, value, units, cylsize=512)
Holey partition/slices
----------------------
Holes within the partition/slice table will not be reported
by TD. The following functions will be provided to allow
a consumer to get a list of holes within partitions/slices.
def Partition.get_gaps(self, size_units=Target.SIZE_UNITS_GB)
'''
Returns a tuple containing HoleyPartition objects corresponding
to the spaces within partitions. The HoleyPartition objects
are available to the partition to use when increasing the size.
The sum of the size of both HoleyPartitions determines the
maximum additional size this partition can grow by.
size_units indicates the default human readable size units
format used in each HoleyPartition object in the returned tuple.
If HoleyPartitions exist on both sides of the partition
then the corresponding tuble will be of the form:
(Before, After)
If no adjacent space exists on a given side of the partition then
the corresponding tuble will contain the None. (None, After) or
(Before, None)
If no adjacent space exists on either side of the partition
then the returned tuple will be (None, None)
'''
def Slice.get_gaps(self, size_units=Target.SIZE_UNITS_GB)
'''
Same as for Partition object
'''
[1] Target.DESIRED needs to reflect the state of the targets
in the DOC as they should be laid out by TI. So, if
modifications to physical and logical devices needs to
be made, it can be done as follows:
target = Target.DESIRED
disk = target.get_descendants( .. )
slice1 = Slice("1")
slice1.action = "preserve"
slice2 = Slice("2")
slice2.action = "preserve"
partition1 = Partition("1")
partition1.action = "create"
partition1.type = "primary"
partition1.bootid = 0x80
partition1.size = ..
partition1.insert_children([slice1, slice2])
disk.insert_children([partition1])
zpool = Zpool("mypool")
zpool.action = "create"
vdev = Vdev("vdev")
dataset = Dataset("dataset")
fs = Filesystem("mypool/user1")
fs.action = "create"
dataset.insert_children(fs)
vdev.insert_children(disk)
zpool.insert_children([vdev, dataset])
Note that the logical stuff needs to change a LOT
once the target schema changes are made. Also note that
more examples on do something like above can be found
in the cud_ti gate under the 'install_target/test' directory.
Alok
_______________________________________________
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
