We are developing a new Project named COMSTAR (http://opensolaris.org/os/project/comstar/). It is something like a virtual FC storage with real file system. The COMSTAR will utilize existing disks or ZFS. When we think about the ereport of FMA in COMSTAR, we think the COMSTAR is something as the same as ZFS. [Eric] When you say 'or ZFS', do you mean zvols, or raw access to the DMU? How is COMSTAR the same as ZFS? [David] I should say 'ZFS volumes'; In some way, COMSTAR will be a file system oriented service (zfs, ufs) instead of block oriented service (sd, ssd).
The COMSTAR will consume information from disks and ZFS both, the COMSTAR will also generate ereports by itself. [Eric]What additional diagnosis will you be providing above and beyond what is already being done by ZFS and (eventually) the SCSI/FMA work? I don't see why we need another layer of diagnosis, but perhaps I'm missing something. [David] I think COMSTAR will also have some internal failures; Since COMSTART will use ZFS as a storage device, ZFS failure may cause COMSTART failure. For SCSI, COMSTART will also use it. I should say COMSTAR is a consumer of both raw disks and ZFS volumes. [Eric]I think the important thing here is to focus on customer-visible faults. If a disk or ZFS vdev fails, then we will have already produced a diagnosis for the faulty resource. If this causes errors higher up in the stack, we should *not* be diagnosing those resources as faulty, because the underlying problem is deeper in the stack. What you need to pay attention to is whether there are faults that only exist (or can only be detected at) the COMSTAR level. In ZFS, for instance, we have the ability to detect checksum errors that the hardware cannot detect, as well as have vdevs based on things other than raw disks. Therefore, it makes sense to implement diagnosis at this level. COMSTAR certainly can consume faults for the purpose of proactively degrading or offlining devices, but as I mentioned below I believe the generic I/O retire framework is better suited for this task.
If ZFS volume generates a fault, what all information we have available to consume? [Eric] The fault payloads are documented in the FMA events gate (events.central). 2) Further, if we have to write our own Eversholt rules, what all information can we consume from ZFS? [Eric]Eversholt is very limited, and cannot deal with FMRIs outside the hc:// scheme, or consumer 'other' information. So the answer is "none". 3) Did you develope a new DE in C or just utilize eft DE as default? We may follow your successful experiences. [Eric] The ZFS DE is written in C. 4)For the C based DE, are you using FMD PRM in fma.eng? Would you mind pointing us your code that we can look it as a reference? [Eric] You can find the code in usr/src/cmd/fm/modules/common/zfs-diagnosis/ 5) For libtopo, the fma.eng hasn't given any useful documents. Would you please forward us your code and PRM as well. (I may need to ask FMA team also) [Eric] No, there is no documentation for libtopo whatsoever. You can find examples in usr/src/lib/fm/topo/modules/
If we write our own retire agent, what all can be used from ZFS? [Eric] Assuming you're targeting ON, then anything in libzfs is fair game. But again, we have a generic I/O retire framework now, so why have your own agent? 2) Is I/O retire ready for us? If we have it, we needn't do anything right? [Eric] Vikram Hegde integrated the I/O retire facility a while ago. As part of this infrastructure, participating consumers must register a callback that allows the framework to break a device contract in the event of I/O retire. So you do have to plug into it, but it already exists and is, AFAIK, complete. 3) For I/O retire, are there any PRM guide also? [Eric] No, your best source of information is the PSARC case (2007/290) and Vikram himself.
There is a "ZFS phrase N" in <2007.015.UnifiedDisk>".We need your advice really. Because, our COMSTAR will also consume disks information. [Eric] I'm not sure what you're asking here. I'm happy to give advice, but I'm afraid I don't really understand the problem you are trying to solve. [David] Actually, there is a chart in the portfolio which displays a serious of phrases of ZFS work (phrase1,2 ...) I just want to ask how much thought you have put into 'ZFS phase N' at this point. If we will eventually have phrase N, shall we use phrase 1,2 as well. [Eric] The next phase of ZFS/FMA integration will correlate disk faults and vdev faults in a more coordinated fashion. Primarily this will involve issuing a suspect list that includes both the disk and vdev, possibly weighted differently depending on the diagnosis (for example, I/O failures are 100% the fault of the device, while checksum errors may or may not be). The bulk of the diagnosis will remain the same. - Eric