RE:

#1 (**permalink**) 07-11-2006

This is a multi-part message in MIME format.

--===============1767679051==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C6A50E.D0BB24E5"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6A50E.D0BB24E5
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dave,

Many thanks for your quick response. Any idea what the timeframe may be =
of such a fix? We have a reasonably urgent need for it.=20

Dana

-----Original Message-----
From: Dave Shield [mailto:D.T.Shield@csc.liv.ac.uk]
Sent: Tue 7/11/2006 5:12 AM
To: Dana Heath
Cc: net-snmp-coders@lists.sourceforge.net
Subject: Re:=20
=20
Dana Heath wrote:

> Turns out that when mount points change dynamically, there is a=20
> problem with how the hrStorage table reports these mount points. The=20
> 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 =3D STRING: =
/home/dana/mnt/cittio
> HOST-RESOURCES-MIB::hrStorageDescr.12 =3D STRING: /fc4
>
> Unmounting /fc4 ... Now let's add another mountpoint and examine the=20
> results:
> HOST-RESOURCES-MIB::hrStorageDescr.11 =3D STRING: =
/home/dana/mnt/cittio
> HOST-RESOURCES-MIB::hrStorageDescr.13 =3D STRING: =
/home/dana/mnt/chimera
>
> hold on here, Charlie! what happened to the table entry at index=3D12? =

> Of course it was removed, but shouldn't the new mount point take=20
> 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=20
disk partitions)
should have different index values. /home/dana/mnt/chimera is=20
(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 =3D STRING: =
/home/dana/mnt/cittio
> HOST-RESOURCES-MIB::hrStorageDescr.13 =3D STRING: =
/home/dana/mnt/chimera
>
That's definitely a bug.

> if I now unmount the previously mounted entry:
> HOST-RESOURCES-MIB::hrStorageDescr.11 =3D STRING: =
/home/dana/mnt/cittio
> HOST-RESOURCES-MIB::hrStorageDescr.12 =3D 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=20
> problem, but rather the hrStorage code itself dealing with the list=20
> 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=20
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=20
Get_Next_HR_FileSys()
can be in "random" order, which confuses the table handling code. I=20
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=20
/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=20
code to handle
this properly. Thanks for bringing it to our attention.

Dave

------_=_NextPart_001_01C6A50E.D0BB24E5
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7638.1">
<TITLE>RE: </TITLE>
</HEAD>
<BODY>


Dave, 
 
Many thanks for your quick response. Any idea what the timeframe may be =
of such a fix? We have a reasonably urgent need for it. 
 
Dana 
 
 
-----Original Message----- 
From: Dave Shield [<A =
HREF=3D"mailto:D.T.Shield@csc.liv.ac.uk">mailto:D. T.Shield@csc.liv.ac.uk<=
/A>] 
Sent: Tue 7/11/2006 5:12 AM 
To: Dana Heath 
Cc: net-snmp-coders@lists.sourceforge.net 
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 =3D STRING: =
/home/dana/mnt/cittio 
> HOST-RESOURCES-MIB::hrStorageDescr.12 =3D STRING: /fc4 
> 
> Unmounting /fc4 ...  Now let's add another mountpoint and =
examine the 
> results: 
> HOST-RESOURCES-MIB::hrStorageDescr.11 =3D STRING: =
/home/dana/mnt/cittio 
> HOST-RESOURCES-MIB::hrStorageDescr.13 =3D STRING: =
/home/dana/mnt/chimera 
> 
> hold on here, Charlie! what happened to the table entry at =
index=3D12? 
> 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 =3D STRING: =
/home/dana/mnt/cittio 
> HOST-RESOURCES-MIB::hrStorageDescr.13 =3D STRING: =
/home/dana/mnt/chimera 
> 
That's definitely a bug. 
 
> if I now unmount the previously mounted entry: 
> HOST-RESOURCES-MIB::hrStorageDescr.11 =3D STRING: =
/home/dana/mnt/cittio 
> HOST-RESOURCES-MIB::hrStorageDescr.12 =3D 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 
 



</BODY>
</HTML>
------_=_NextPart_001_01C6A50E.D0BB24E5--

--===============1767679051==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-------------------------------------------------------------------------
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=...057&dat=121642

--===============1767679051==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/...et-snmp-coders

--===============1767679051==--

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode