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].
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
- 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
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
