Hi Matt,
On Fri, 14 Jan 2011, Matt Keenan wrote:
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 ?
That is correct. If a validation error occurs, the error service
will describe exactly what kind validation error it is (p2 already
exists or somesuch).
It would be up to the app/target controller to determine the
severity of that error, i.e. is a "soft" error or a "hard" error.
Between the app and the target controller there is enough
context to determine which it is. TI on the other hand, really
doesn't have that kind of context.
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/controller won't necessarily have the logic to determine
*if* number of partitions is greater than 4, it is an error. But
it *would* need to know the list of errors that it considers to
be "soft" and others that it considers to be "hard". And, what
it needs to do deal with/clear those errors (for example: call
partition.delete() on p2 that it really should have done).
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.
Yep, thanks for pointing that out. I'll add it to the
list.
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.
I would lean towards not doing this sort of validation at all
in TI/TD. Quite possibly let zfs deal with it or have it be
dealt at a higher level, higher than TI/TD.
This would be in the same vein as not validating zpool/dataset
properties in TI/TD but letting zfs take care of that.
Or validation that a vdev which exists in one redundancy type cannot be part
of another redundancy.
Ooh, that needs to be added. Will add.
Alok
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
