|
From: Heidi N. <HEI...@de...> - 2001-11-20 08:30:00
|
Marcin , its great to see your interest in SBLIM . The way I was implementing the new getInstance() method was fast and - please excuse - very dirty ! You are absolutelly right - this needs to be changed ! The way I am going at the very moment - asking the CIMOM to enumerate all instances - is NOT the way it has to be done ! The provider itself has direct access to the resources he has to manage and this advantage has to be used . The most efficience way to implement the getInstance() method is a seperate method in CimFsVol.c . This is the library to access the resources , collect the data and preparing them for the class provider . This will be fixed but at the very moment I'm pretty busy and "fighting" ;-) with the LVM instrumentation part . In terms of data consistency and performance a provider cache would not be the best solution for FSVOL . That solution would force overhead in memory management and you lose performance . Its not necessary for this kind of provider . Maybe in another content such a solution would be the best way to go but here I recommend to use the direct access . > I'm not sure, but from what you're saying getInstance gets only "Name" property? No - If you take a look at the input parameter of the getInstance() method you see that there is a CIMObjectPath submitted to the method . The CIMObjectPath consists of the namespace and the key values of the instance you want to get all the data for . In the case of LocalFileSystem these key values are CSCreationClassName , CSName , CreationClassName and Name . I use the "Name" to serve as filter . >> http://w3.opensource.ibm.com/projects/ibmcimom/ >What is the ibmcimom project? Is IBM involved in creating it's own CIMOM? Sorry :-o - that's our IBM internal URL for SBLIM . The page hosts the same content like SBLIM . We will not create an own CIMOM . by ... heidi Mfg / Regards Heidi Neumann Linux Technology Center - Systems Management - IBM Laboratory Boeblingen - Germany - Schönaicher Str. 220 - 71032 - Böblingen Phone : ++49 (0) 7031 / 16 - 3193 hei...@de... http://oss.software.ibm.com/developerworks/projects/sblim/ __________________ On Mon 12. November 2001 14:26, you wrote: > The effect is based on the implementation of the "getInstance" Hmm, I can see the problem, but probably the JVM shouldn't crash anyway ;-) > method . As you can see in the code the CIMObjectPath parameter > is used to extract the mount point of the filesystem ( in the > current implementation stored in key "Name" ) . this mount point > is then used to get all the other information about this special > filesystem instance ( via getmntent() and a comparision between > "Name" and mnt_dir ) . If you swap the content of the properties > this possibility is lost . Now you need the instance instead of I'm not sure, but from what you're saying getInstance gets only "Name" property? I couldn't find any NPI docs and I haven't got so much time to dig all the way through NPI code to find out. If so then it would be rational to create some sort of a "provider cache" because enumeration of all the instances stored in the CIMOM for every getInstance operation can be pretty expensive (in regard both to CPU and to network utilization). I thought of a simple cache that would be able to hold the result of enumInstances so that getInstance would only need to look up in the cache whether object of given name exists or not. The cache should be as general as possible - i.e. it should be useful for RPM, fsvol and also for future providers. I thought of a simple hashing table implementation, though maybe some kind of Trie tree would be better? Another question that needs to be answered before trying to implement such a cache is what kind of information exactly has to be stored in the cache. The Name property serves as the key (together with the namespace) but what is the value? Is it enough to store CIMInstance returned by makeInst? With such a cache enumInstance would invalidate all the existing cache entries of the same class in the same namespace and create a vector of all instances currently available on the computer. The vector would be returned to CIMOM and also the elements stored in the cache. Then getInstance would be a mere check if the object exists in the cache or not. > This change has impact to the association LVM_ResidesOnExtent.c > too . I was thinking about implementing its functionality in only > one provider ( this would be Linux_ResidesOnExtent.c ) . What do > you think ? Would this make sense ? Frankly I do not feel competent to say anything as I haven't got LVM on my computer and haven't had (yet) contact with LVM. Hope to change it in the nearest future ;-) > http://w3.opensource.ibm.com/projects/ibmcimom/ What is the ibmcimom project? Is IBM involved in creating it's own CIMOM? gozdal@master:~$ host -t ns ibm.com ibm.com NS NS.AUSTIN.ibm.com ibm.com NS NS.WATSON.ibm.com ibm.com NS NS.ALMADEN.ibm.com ibm.com NS INTERNET-SERVER.ZURICH.ibm.com ibm.com NS NS.ERS.ibm.com gozdal@master:~$ host -a w3.opensource.ibm.com NS.ERS.ibm.com w3.opensource.ibm.com does not exist at NS.ERS.ibm.com (Authoritative answer) -- Marcin Gozdalik <go...@go...> _______________________________________________ Sblim-devel mailing list Sbl...@ww... http://www-124.ibm.com/developerworks/oss/mailman/listinfo/sblim-devel |