Menu
▾
▴
sblim-devel
|
From: Heidi N. <HEI...@de...> - 2001-11-13 08:32:51
|
Marcin , I swapped the "Root" and "Name" properties in Linux_LocalFileSystem . The effect was the same as you described ! The effect is based on the implementation of the "getInstance" 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 the CIMObjectPath to get this important mount point . You are right that the properties are swapped and I implemented your suggestion . This change had impact to the class Linux_ResidesOnExtent.c too . The fixed code is in the CVS now . Please have a look at it . 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 ? ! I did not fix the LVM_ResidesOnExtent provider ! ! This provider will not run ! Have fun . 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://w3.opensource.ibm.com/projects/ibmcimom/ http://oss.software.ibm.com/developerworks/projects/sblim/ |
|
From: Marcin G. <go...@go...> - 2001-11-17 00:40:27
|
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...> |
|
From: <mih...@t-...> - 2001-11-18 21:47:35
|
Hi Marcin, I let Heidi answer the fsvol and LVM questions (out of politeness and as I'm not competent enough to do so :-). But I wanted to understand the rationale behind your "Provider Cache" thoughts, as I do not see that a getInstance call would result in enumInstances (although I could imagine that this happens for associators). Marcin Gozdalik (by way of Marcin Gozdalik ) wrote: > > 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). > Regards, Viktor |
|
From: Marcin G. <go...@go...> - 2001-11-18 21:56:10
|
On Sun 18. November 2001 19:45, you wrote: > rationale behind your "Provider Cache" thoughts, as I do not see that a > getInstance call would result in enumInstances (although I could imagine > that this happens for associators). The rationale behind my idea is the new getInstance fsvol implementation: nameSpace = CIMObjectPathGetNameSpace( nh , cop ); cLD = CIMObjectPathNew( nh, "Linux_LocalFileSystem" ); CIMObjectPathSetNameSpace( nh , cLD , nameSpace ); ->vi = CIMOMEnumInstances( nh , cLD ,0 ,0); size = VectorSize(nh,vi); nm = CIMObjectPathGetStringKeyValue( nh, cop, "Name"); I think that it's simply easier to do this locally, without involving CIMOM to do enumInstances for us. Since getInstance is called after enumInstances has been called I think enumInstances could cache all the relevant information so that getInstance would be faster. This observation also grew from the speed of executing getInstance on not-so-weak machine (Duron 750,384MB RAM) with SNIA CIMOM - enumInstances was acceptable but clicking on any Linux_LocalFileSystem in openCIMOM browser takes 1-2 seconds to execute which I think is pretty bad. Cheers, Marcin -- Marcin Gozdalik <go...@go...> |
|
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 |
|
From: Marcin G. <go...@go...> - 2001-11-20 02:28:04
|
On Mon 19. November 2001 15:44, you wrote: > 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 . Well, some kind cache is inevitable IMHO. Simply enumInstancesNames returns names of currently mounted filesystems but before CIMOM issues a getInstance somebody could remount some of the filesystems, so getInstance would have to return an error which isn't an expected behaviour. Or was this whole situation thought of before and it's covered somewhere in the CIMOM specs I haven't got the opportunity to read? -- Marcin Gozdalik <go...@go...> |
|
From: Viktor M. <MIH...@de...> - 2001-11-20 11:18:06
|
Hi Marcin,
the behaviour in the case described is just right, if the filesystem has
been unmounted (e.g., bypassing the CIMOM), it is effectively no longer
there and hence should not be returned by getInstance. A cache would have
to account for this situation as well for coherency reasons, which is at
least difficult, if not impossible. Don't want to go into the evil details,
but imagine multiple clients that are accessing the CIMOM in parallel AND
somebody modifying the real resources....
Mit freundlichen Grüßen / Kind Regards
Viktor Mihajlovski
Linux Technology Center
IBM Laboratory Böblingen, Germany
Phone +49-7031-16-2560
E-Mail mih...@de...
Marcin Gozdalik
<go...@go...> To: Heidi Neumann/Germany/IBM@IBMDE
Sent by: cc: sbl...@ww...
sblim-devel-admin@www-1 Subject: Re: [Sblim-devel] Java VM bug?
26.ibm.com
11/20/01 12:26 AM
Please respond to
Marcin Gozdalik
On Mon 19. November 2001 15:44, you wrote:
> 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 .
Well, some kind cache is inevitable IMHO. Simply enumInstancesNames returns
names of currently mounted filesystems but before CIMOM issues a
getInstance
somebody could remount some of the filesystems, so getInstance would have
to
return an error which isn't an expected behaviour. Or was this whole
situation thought of before and it's covered somewhere in the CIMOM specs I
haven't got the opportunity to read?
--
Marcin Gozdalik <go...@go...>
_______________________________________________
Sblim-devel mailing list
Sbl...@ww...
http://www-124.ibm.com/developerworks/oss/mailman/listinfo/sblim-devel
|
Thanks for helping keep SourceForge clean.
X