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>Received on Thu Oct 06 2011 - 04:56:23 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:18 UTC