On Wed, 2005-08-17 at 16:25 -0400, Salyzyn, Mark wrote: > Under aac based adapters the build task reports the task number, current > array water mark and end of array but not the array number associated > with the build task in the AIF events returning from the Firmware. The > management applications generally issue a series of enumerations to the > devices and the arrays to build a set of objects, one of these object > attributes is the build task associated with the array (if it is > rebuilding). > > Really simple to report the percentage completed as the driver already > sniffs the AIFs to generate hot-add and hot-remove actions, much more > difficult and quite possibly driver bloating to associate that build > task status with an array or underlying targets. Yes, fusion also necessitates some digging to get the correct information. > Compromise? Well, what about exporting an raid adapter class and having > 'resync' associated with that adapter object? Array creation will no > doubt have to go to the raid adapter class in any case, so it will be a > requirement if configuration is to be allowed in this RAID class. But isn't that what you currently have? The HBA exports a get_resync() method via the function templates which the raid class makes use of. I admit that the whole thing will get hugely complex if configuration becomes allowable via this class, but at the moment I'm just trying to get at useful information display ... configuration can come later. > Add hotspare-0, hotspare-1 ... to the list? Yes ... I only have two disks though, so I've reached the limit of what I can do with my current fusion setup. The whole of the component display has to be reworked anyway (I only provide add, but obviously delete should be allowed as well as component type). I'll add it to the list. Probably we also need a component state model as well (and perhaps spare would be one of the states). > A target id written to resync would be used to 'suck in' a hotspare or > trigger a rebuild to a failed target? Actually, probably do that via an echo to the state. The user would be allowed to kick certain state transitions, and degraded->resyncing should probably be one of them. James - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
