Hi,
something that comes to my mind would be a slight(?) modification of the
schema. How about modelling extents as groups and not as single
entities. I would expect that extents are usually handled in a way that
<n> consecutive extents are assigned to a logical volume at once instead
of one at a time. Of course one could still assign single extents, in
which case we would end up with single-extent groups (being the just
penalty for this kind of folly:-).
Any thoughts or comments on that?
>
> "Heidi Neumann" <HEI...@de...> on 18/07/2001 16:08:06
>
> Please respond to "Heidi Neumann" <HEI...@de...>
>
> To: sbl...@dw..., ibm...@op...
> cc:
>
> Subject: [Ibmcimom-devel] discussion point : How to handle mass
> operations ?!?
>
> Hi ,
>
> the goal of this mail is to start a discussion about how
> to handle mass operations . It is not always the best
> solution to avoid them .
>
> At the moment I'm running in such a mass problem with
> the instrumentation of "Filesystems & Volume Management"
> and I'm not sure how to solve the forced crashes .
>
> PROBLEM DESCRIPTION
>
> - affected module : sblim-fsvol-0.6.1 ( tar.gz )
> FSVOL_0_6_1 ( CVS tag )
> - affected part : the instrumentation of the Logical
> Volume Manager for Linux (LVM)
>
> - affected class : LVM_PVExtent
> Each instance of the class LVM_PVExtent represents one
> physical extent in the Linux Logical Volume Manager (LVM) .
>
> - provider code :
>
> * com/ibm/wbem/linux/device/LVM_PVExtent.java :
> calling the NPI - uninteresting in the problem
> environment
>
> * LVM_PVExtent.c :
>
> 1 step : enumeration of all physical volumes
> -> 6 physical volumes
>
> 2 step : for each instance of the physical volume
> all physical extents are collected in a list
> -> ~ 4000 = sum of all physical extents
> ! this happens in functions of the tool
> library CimFsVMgmt.c whithout any problems !
>
> 3 step : for each entry in the list of physical
> extents one instance of LVM_PVExtent is
> created ... no - should be created
>
> This enumeration of all instances of the class LVM_PVExtent
> brings on the problem how to handle this mass operation
> and avoid crashes .
>
> Now one discussion point can be why it seems to be
> necessary to do such a "maybe useless" operation . It is,
> from a systems management application view, really necessary
> to get all the physical extents of one system to have a look
> in the way they are connected to their corresponding logical
> extents and the logical volume ? What might be a case where
> this granularity becomes important ( Standard value fo a
> physical extent is 4096 kB !!! ) .
> Or shall there be other ways to offer detailed informations .
>
> An other discussion point can be, how to solve such problems
> whithout avoiding enumerations with a mass result . I' sure
> that there are other environments where it is not possible
> to strike out operations that have a mass result .
>
> Now follow some possible solutions as discussion basics .
>
> POSSIBLE SOLUTIONS
>
> * increase the memory allocation size for the Java Virtual
> Machine ???
>
> * take this granularity out of the schema
> ( delete LVM_PVExtent ) ???
>
> * more suggestions ???
>
> Thanks for your attention ... Heidi
>
> Mfg / Regards
>
> Heidi Neumann
>
> IBM Laboratory Boeblingen - Germany - Dept. 3243
> LTC - - Linux Technology Center -- 7UFA
> Systems Management
>
> Phone : ++49 (0) 7031 / 16 - 3193
> Schönaicher Str. 220, 71032 Böblingen
>
> hei...@de...
> --- try sametime to contact me ---
>
> http://w3.opensource.ibm.com/projects/ibmcimom/
> http://oss.software.ibm.com/developerworks/projects/sblim/
>
> _______________________________________________
> Ibmcimom-devel mailing list
> Ibm...@op...
> http://w3.opensource.ibm.com/mailman/listinfo/ibmcimom-devel
--
Kind Regards / Mit freundlichen Grüßen
Viktor Mihajlovski
Linux Technology Center
IBM Laboratory Böblingen, Germany
Phone +49-7031-16-2560
Email mih...@de...
|
