> Turns out that removing that entire block of code in hr_filesys.c around
> line 600 fixes the problem:
Yes - that would work (since it returns the code to its original,
"monotonically increasing" behaviour).
> 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?
Because of the definition of the table index object:
"A unique value for each logical storage area
contained by the host."
If the agent is reporting on the same storage area in response
to two different queries, then it should use the same index value
both times - regardless of what fiddling about might have been
done in the meantime.
The management application should need to care whether
disks have been unmounted and remounted - if /home/wombat
was index 23 yesterday, then it ought to be index 23 today.
(assuming the agent hasn't been restarted, in which case all
bets are off).
> 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.
The current implementation should (apart from this bux) report mount
points in a *consistent* order - that's really all that matters. It's not
important what this order actually is (alphabetic, by time, by size,
etc) - just that the management side can rely on the indexes being
stable.
You've uncovered a bug, which we need to fix. And it's a perfectly
reasonable workaround to drop the persistent index code. But
the real solution is to keep this persistent index code *and* to fix
the implementation so that it doesn't choke.
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
