RFC: Project geom-events

[Lev Serebryakov]

Hello, John-Mark.
You wrote 6 октября 2011 г., 2:53:53:

>>    gmirror0
>>      gstripe0
>>        ada0
>>        ada1
>>      gstripe1
>>        ada2
>>        ada3
>> 
>>   and administrator kills gstripe0, for example, geom_mirror will send
>>  event, because from its point of view it is not administrative
>>  action...
>>   But such situations, IMHO, are not very often ones.
> Won't gmirror still report COMPLETE after a gmirror remove?  So the
  I say "kill gstripe0", not "Remove gstripe0 from gmirror0", it is
different situations. gmirror0 will be DEGRADED after this action, but
will send DISCONNECT message with "fixable" state and it is state when
geom-events(8) try to find replacement (spare). Exactly as when it
lost component due to accident. If you say "gmirror remove", yes, it
will be COMPLETE after it.

> script can look at the gmirror device, and see that it is still
> complete even though one of the providers were dropped and assume
> it was an administrative command that did it..
   Here is one problem: there is no STANDARD way to understand state of
 provider from userland, as it is GEOM-specific. "g${class} status ${geom}" prints almost
 free-form information. Not all classes names it "COMPLETE", and some
 classes (geom_raid, for example) could have many providers and many
 states, which adds complexity. So, to make it work this way I need to
 add knowledge about all classes and their output formats to
 geom-ecents(8). I don't think, that it is good design -- it is bad
 idea to put knowledge about GEOM classes in two places -- class
 itself and some script. It will hard to synchronize, etc. So, I
 think, GEOM class itself should decide and report its state in
 standard way.

-- 
// Black Lion AKA Lev Serebryakov <lev at FreeBSD.org>