Turns out that removing that entire block of code in hr_filesys.c around line 600 fixes the problem:
HRFS_index = se_find_value_in_slist("filesys", HRFS_entry->HRFS_name );
if (HRFS_index == SE_DNE) {
HRFS_index = se_find_free_value_in_slist("filesys");
if (HRFS_index == SE_DNE) { HRFS_index = 1; }
se_add_pair_to_slist( "filesys",
strdup( HRFS_entry->HRFS_name ), HRFS_index);
}
I'm aware that this assigns a new index to a previously existing mount point, but if the mount point was unmounted and then re-mounted, why should it have to maintain a session index? Seems illogical to me since the current implementation doesn't report the mount points in the order they were mounted, even if this bug didn't exist.
-----Original Message-----
From: Dave Shield [mailto:[EMAIL PROTECTED]]
Sent: Tue 7/11/2006 5:12 AM
To: Dana Heath
Cc: [email protected]
Subject: Re:
Dana Heath wrote:
> Turns out that when mount points change dynamically, there is a
> problem with how the hrStorage table reports these mount points. The
> following scenario describes my problem:
>
> An initial walk of the hrStorage tree returns the following data on my
> box [relevant part copied]:
> HOST-RESOURCES-MIB::hrStorageDescr.11 = STRING: /home/dana/mnt/cittio
> HOST-RESOURCES-MIB::hrStorageDescr.12 = STRING: /fc4
>
> Unmounting /fc4 ... Now let's add another mountpoint and examine the
> results:
> HOST-RESOURCES-MIB::hrStorageDescr.11 = STRING: /home/dana/mnt/cittio
> HOST-RESOURCES-MIB::hrStorageDescr.13 = STRING: /home/dana/mnt/chimera
>
> hold on here, Charlie! what happened to the table entry at index=12?
> Of course it was removed, but shouldn't the new mount point take
> position 12?
>
No.
Check the MIB description for hrStorageIndex:
"A unique value for each logical storage area contained by the host."
Note "unique" - that means that different storage areas (in this case
disk partitions)
should have different index values. /home/dana/mnt/chimera is
(presumably) not the
same partition as /fc4, so it needs to have a different index.
There's code towards the end of host/hr_filesystem.c:Get_Next_HR_FileSys()
explicitly to implement this behaviour.
> Let's now examine what happens when we remount /fc4... one would think
> that since index 12 was skipped, it would be re-inserted at position 12,
>
That's what ought to happen, certainly.
> so let's take a look at the results:
> HOST-RESOURCES-MIB::hrStorageDescr.11 = STRING: /home/dana/mnt/cittio
> HOST-RESOURCES-MIB::hrStorageDescr.13 = STRING: /home/dana/mnt/chimera
>
That's definitely a bug.
> if I now unmount the previously mounted entry:
> HOST-RESOURCES-MIB::hrStorageDescr.11 = STRING: /home/dana/mnt/cittio
> HOST-RESOURCES-MIB::hrStorageDescr.12 = STRING: /fc4
> and there it is again. This behavior leads me to believe that there is
> a bug in the hrStorage code that is not indicative of a system
> problem, but rather the hrStorage code itself dealing with the list
> management of the mount points.
>
I've had a quick look, and think I've spotted the problem.
The original implementation returned didn't have the special code for
persistent indexes, and
simply returned entries from /etc/mtab (or equivalent) in the order that
they appeared there.
The index values were strictly increasing, and everything worked fine.
With the new persistent index handling, the index values returned from
Get_Next_HR_FileSys()
can be in "random" order, which confuses the table handling code. I
suspect that if you:
mount /fc4
mount /home/dana/mnt/chimera
umount /fc4
mount /fc4
[so that walking hrStorageDescr skips /fc4], and then manually edit
/etc/mtab to move
the entry for /fc4 *before* that for /home/dana/mnt/chimera, then things
will display
correctly again.
That's not a solution to the problem, obviously. We do need to fix the
code to handle
this properly. Thanks for bringing it to our attention.
Dave
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
