Menu
▾
▴
net-snmp-coders — Discussion of internal project coding (Please use this OR -users, NOT both!)
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(14) |
Nov
(315) |
Dec
(298) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(254) |
Feb
(467) |
Mar
(430) |
Apr
(345) |
May
(406) |
Jun
(336) |
Jul
(313) |
Aug
(265) |
Sep
(433) |
Oct
(462) |
Nov
(387) |
Dec
(232) |
| 2002 |
Jan
(352) |
Feb
(556) |
Mar
(463) |
Apr
(500) |
May
(557) |
Jun
(337) |
Jul
(317) |
Aug
(279) |
Sep
(273) |
Oct
(354) |
Nov
(267) |
Dec
(347) |
| 2003 |
Jan
(351) |
Feb
(445) |
Mar
(520) |
Apr
(665) |
May
(499) |
Jun
(393) |
Jul
(304) |
Aug
(425) |
Sep
(262) |
Oct
(329) |
Nov
(220) |
Dec
(174) |
| 2004 |
Jan
(365) |
Feb
(479) |
Mar
(515) |
Apr
(522) |
May
(214) |
Jun
(471) |
Jul
(292) |
Aug
(341) |
Sep
(243) |
Oct
(446) |
Nov
(294) |
Dec
(147) |
| 2005 |
Jan
(171) |
Feb
(209) |
Mar
(218) |
Apr
(321) |
May
(233) |
Jun
(534) |
Jul
(268) |
Aug
(345) |
Sep
(498) |
Oct
(557) |
Nov
(459) |
Dec
(238) |
| 2006 |
Jan
(288) |
Feb
(180) |
Mar
(151) |
Apr
(113) |
May
(164) |
Jun
(277) |
Jul
(160) |
Aug
(383) |
Sep
(221) |
Oct
(404) |
Nov
(358) |
Dec
(163) |
| 2007 |
Jan
(293) |
Feb
(175) |
Mar
(202) |
Apr
(155) |
May
(427) |
Jun
(484) |
Jul
(414) |
Aug
(125) |
Sep
(131) |
Oct
(160) |
Nov
(79) |
Dec
(70) |
| 2008 |
Jan
(133) |
Feb
(115) |
Mar
(158) |
Apr
(194) |
May
(197) |
Jun
(230) |
Jul
(146) |
Aug
(68) |
Sep
(93) |
Oct
(53) |
Nov
(95) |
Dec
(69) |
| 2009 |
Jan
(81) |
Feb
(162) |
Mar
(215) |
Apr
(216) |
May
(78) |
Jun
(131) |
Jul
(61) |
Aug
(176) |
Sep
(127) |
Oct
(28) |
Nov
(83) |
Dec
(94) |
| 2010 |
Jan
(100) |
Feb
(187) |
Mar
(320) |
Apr
(161) |
May
(194) |
Jun
(142) |
Jul
(129) |
Aug
(139) |
Sep
(239) |
Oct
(202) |
Nov
(139) |
Dec
(196) |
| 2011 |
Jan
(195) |
Feb
(191) |
Mar
(201) |
Apr
(127) |
May
(84) |
Jun
(126) |
Jul
(101) |
Aug
(237) |
Sep
(123) |
Oct
(104) |
Nov
(197) |
Dec
(114) |
| 2012 |
Jan
(65) |
Feb
(85) |
Mar
(129) |
Apr
(84) |
May
(94) |
Jun
(83) |
Jul
(89) |
Aug
(85) |
Sep
(89) |
Oct
(73) |
Nov
(34) |
Dec
(38) |
| 2013 |
Jan
(89) |
Feb
(30) |
Mar
(25) |
Apr
(18) |
May
(20) |
Jun
(45) |
Jul
(74) |
Aug
(37) |
Sep
(72) |
Oct
(30) |
Nov
(67) |
Dec
(24) |
| 2014 |
Jan
(23) |
Feb
(16) |
Mar
(40) |
Apr
(37) |
May
(12) |
Jun
(18) |
Jul
(30) |
Aug
(26) |
Sep
(24) |
Oct
(32) |
Nov
(15) |
Dec
(33) |
| 2015 |
Jan
(15) |
Feb
(45) |
Mar
(21) |
Apr
(24) |
May
(22) |
Jun
(7) |
Jul
(57) |
Aug
(17) |
Sep
(16) |
Oct
(3) |
Nov
(8) |
Dec
(13) |
| 2016 |
Jan
(7) |
Feb
(14) |
Mar
(40) |
Apr
(8) |
May
(10) |
Jun
(6) |
Jul
(8) |
Aug
(10) |
Sep
(19) |
Oct
(20) |
Nov
(45) |
Dec
(10) |
| 2017 |
Jan
(10) |
Feb
(12) |
Mar
(3) |
Apr
(17) |
May
(41) |
Jun
(21) |
Jul
(13) |
Aug
(13) |
Sep
(7) |
Oct
(23) |
Nov
(10) |
Dec
(23) |
| 2018 |
Jan
(45) |
Feb
(3) |
Mar
(57) |
Apr
(107) |
May
(173) |
Jun
(47) |
Jul
(28) |
Aug
(26) |
Sep
(38) |
Oct
(56) |
Nov
(22) |
Dec
(11) |
| 2019 |
Jan
(37) |
Feb
(8) |
Mar
(7) |
Apr
(29) |
May
(32) |
Jun
(5) |
Jul
(21) |
Aug
(31) |
Sep
(38) |
Oct
(8) |
Nov
(13) |
Dec
(10) |
| 2020 |
Jan
(9) |
Feb
(33) |
Mar
(14) |
Apr
(4) |
May
(16) |
Jun
(11) |
Jul
(14) |
Aug
(50) |
Sep
(24) |
Oct
(3) |
Nov
(14) |
Dec
(13) |
| 2021 |
Jan
(18) |
Feb
(15) |
Mar
(12) |
Apr
(9) |
May
(9) |
Jun
(8) |
Jul
(6) |
Aug
(7) |
Sep
(26) |
Oct
(17) |
Nov
(6) |
Dec
(2) |
| 2022 |
Jan
(3) |
Feb
(11) |
Mar
(7) |
Apr
(15) |
May
(5) |
Jun
(4) |
Jul
(29) |
Aug
(6) |
Sep
(7) |
Oct
|
Nov
(4) |
Dec
(1) |
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
(10) |
May
(3) |
Jun
(5) |
Jul
(3) |
Aug
(10) |
Sep
(10) |
Oct
(7) |
Nov
(2) |
Dec
(4) |
| 2024 |
Jan
(22) |
Feb
(5) |
Mar
(11) |
Apr
(20) |
May
(16) |
Jun
(9) |
Jul
(14) |
Aug
(5) |
Sep
(7) |
Oct
(4) |
Nov
(3) |
Dec
|
| 2025 |
Jan
(6) |
Feb
(6) |
Mar
(14) |
Apr
(2) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Michael J. S. <msl...@is...> - 2000-11-10 19:08:35
|
Didier Chabanol wrote: > > Hello, > > I use ucd-snmp V4.1.1. I've compiled a master agent on SunOS5.7 > that support host MIB and MIB II. > Our validation department is making some load test on this particular > master agent. > > We run the master agent on a SunOS5.7. > Then we run the following command on a remote linux : > while [ 1 = 1 ]; do snmpwalk [mastergent_machine_name] public; done > > After 20 hours the master agent crash. SNIP > Have you got any idea ? Have you ever seen this kind of problem ? > > Regards, > > Didier Chabanol > FERMA Try again, this time please use the current version at ftp://ucd-snmp.ucdavis.edu/beta/ucd-snmp-4.2.pre1.tar.gz Regards, -Mike Slifcak, Internet Security Systems, Inc. |
|
From: Bert D. <ber...@nl...> - 2000-11-10 13:39:41
|
"Michael J. Slifcak" wrote: > Bert> It sucks, but what do you do if the OS doesn't instrument it? > Dave> ... if the info is not available, simply say so. > > By returning "noSuchObject" or "noSuchName", as Dave indicated. That's only half the answer: if the MIB calls for seperate read and write counters, but all you've got is the total, then... you're SOL. Actually, since this is our own MIB, we probably could just add an extra object that returns the total. > Dumb question: > > How do you process the number of bytes written to disk ? I don't. :-) > Do you check disk health (MTBF) or test for unusual activity ? That's pretty low-level. It would be cool, but I don't see it happening on UNIX for a looong time. > Do you look for data squirrels (people archiving lots of data) ? We're planning on using Cricket to monitor disk usage on critical machines, but correlating an anomaly back to an individual user remains the good ole handiwork. Cheers, -- Bert -- Bert Driehuis, MIS -- ber...@nl... -- +31-20-3116119 Dihydrogen Monoxide kills! Join the campaign at http://www.dhmo.org/ |
|
From: Didier C. <did...@fe...> - 2000-11-10 13:12:46
|
Hello,
I use ucd-snmp V4.1.1. I've compiled a master agent on SunOS5.7 that
support host MIB and MIB II.
Our validation department is making some load test on this particular
master agent.
We run the master agent on a SunOS5.7.
Then we run the following command on a remote linux :
while [ 1 = 1 ]; do snmpwalk [mastergent_machine_name] public; done
After 20 hours the master agent crash.
Here is the stack obtained by using dbx on core dump.
program terminated by signal SEGV (no mapping at the fault address)
(/opt/SUNWspro/bin/../WS5.0/bin/sparcv9/dbx) where
=>[1] __align_cpy_1(0xffbeccf0, 0x17bff8, 0x18, 0x4, 0x10, 0xffbeccc0),
at 0xff1e0758
[2] getMibstat(0x4, 0xffbeccc0, 0x48, 0x2, 0x36d98, 0xffbecd08), at
0x57230
[3] var_ipAddrEntry(0xffbed008, 0x13bdd0, 0x13bdc0, 0x0, 0xffbed524,
0xffbed51c), at 0x36fe0
[4] search_subtree_vars(0x131130, 0x13bdd0, 0x13bdc0, 0xffbed293,
0x14, 0x131558), at 0x2915c
[5] getStatPtr(0xffbed51c, 0x13a878, 0xffbed52f, 0xffbed524,
0xffbed522, 0x0), at 0x29a54
[6] handle_var_list(0xffbed51c, 0x5, 0xffbed59c, 0xffbed4d0, 0x0,
0x12d270), at 0x283e8
[7] handle_next_pass(0x13a7c0, 0x13a878, 0xffbed798, 0x33, 0xff1b3938,
0xff145590), at 0x2820c
[8] handle_snmp_packet(0x1, 0x13a580, 0x4c109d3a, 0x13a680, 0x0,
0x13a7b5), at 0x27a20
[9] _sess_read(0x12de60, 0xffbef918, 0x0, 0x0, 0x0, 0x0), at 0x7b350
[10] snmp_sess_read(0x12de60, 0xffbef918, 0x1, 0x0, 0xff1b69cc,
0xffffffff), at 0x7b418
[11] snmp_read(0xffbef918, 0xff1b69cc, 0xff1b69cc, 0xff1b69cc,
0xff1b69cc, 0x8), at 0x79e98
[12] receive(0x0, 0x0, 0xffffffff, 0xfffffff8, 0x0, 0x116e49), at
0x269a8
[13] main(0x5, 0xffbefca4, 0xffbefcbc, 0x108800, 0x0, 0x0), at 0x2660c
Have you got any idea ? Have you ever seen this kind of problem ?
Regards,
Didier Chabanol
FERMA
|
|
From: Michael J. S. <msl...@is...> - 2000-11-10 12:47:57
|
Bert> It sucks, but what do you do if the OS doesn't instrument it? Dave> ... if the info is not available, simply say so. By returning "noSuchObject" or "noSuchName", as Dave indicated. Dumb question: How do you process the number of bytes written to disk ? Do you check disk health (MTBF) or test for unusual activity ? Do you look for data squirrels (people archiving lots of data) ? Thanks for clearing my foggy misconception. -Mike Slifcak |
|
From: <ni...@ba...> - 2000-11-10 10:40:47
|
On Thu, 9 Nov 2000 14:33:41 +0100 RADMAN Stefan <Ste...@ct...>
wrote:
>Since my last mail was a little bit too large :) I'll just include the
>essentials this time.
This was very to the point. Thanks!
>CONCLUSION:
>
>snmplib trys to prepend $PREFIX to the oids but in my case this is not meant
>to be an OID prefix but the path prefix I'm using during build.
>Seems that snmplib is getting confused by the "/"s in there and dumps core.
>unset PREFIX and ran the same tests again as root - SUCCEEDED.
It actually failed when it tried to generate the error message! APply the
following patch
--- snmplib/mib.c~ Fri Nov 10 11:33:09 2000
+++ snmplib/mib.c Fri Nov 10 10:36:30 2000
@@ -1252,6 +1252,7 @@
tree_top = (struct tree *)calloc(1,sizeof(struct tree));
/* XX error check ? */
if (tree_top) {
+ tree_top->label = strdup("(top)");
tree_top->child_list = tree_head;
}
}
@@ -1260,7 +1261,10 @@
shutdown_mib (void)
{
unload_all_mibs();
- free(tree_top); tree_top = NULL;
+ if (tree_top) {
+ SNMP_FREE(tree_top->label);
+ free(tree_top); tree_top = NULL;
+ }
tree_head = NULL;
Mib = NULL;
free(Prefix); Prefix = NULL;
@@ -2389,7 +2393,7 @@
{ char buf[256];
if (in_dices) sprintf(buf, "Index: %s, %s, %d %d",
in_dices->ilabel, fcp, pos, len);
- else if (tp) sprintf(buf, "Node: %s, %s", tp->label, fcp);
+ else if (tp) sprintf(buf, "Node: %s -> %s", tp->label, fcp);
else sprintf(buf, "%s", fcp);
snmp_set_detail(buf);
(actually, only the first line is required)
and the result now is
$ PREFIX=/opt/SDCpfe snmptranslate -On system
system: Unknown Object Identifier (Node: (top) -> /opt/SDCpfe)
/Niels
--
Get your firstname@lastname email for FREE at http://Nameplanet.com/?su
|
|
From: Dave S. <D.T...@cs...> - 2000-11-10 08:58:44
|
> It sucks, but what do you do if the OS doesn't instrument it? You either return "noSuchObject" (or noSuchName) or you fudge it. This is essentially the situation we're in with the interface Octet counters. Some architectures support these statistics, but many (particularly the older ones) don't. Traditionally, the CMU agent fudged this by assuming all packets were 308 bytes long, and using that. More recently, we've started following the standards a little more strictly, and return an error. I think the same approach is appropriate here - if the info is not available, simply say so. Dave |
|
From: jaya B. <mbh...@ya...> - 2000-11-10 04:52:28
|
Hello all, I have newly moved to snmp programming side. I have written a MIB file. I need to compile and use that mib file in my project. I need to perform all the operations on the mib like(get,set etc). How do I compile the MIB file using ucd snmp tool kit. Please advise me on this. Regards, Jaya M. __________________________________________________ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one Place. http://shopping.yahoo.com/ |
|
From: beyondsoft <bey...@si...> - 2000-11-10 02:40:27
|
Thank s for ur mention. >>>>> On Thu Nov 9 10:50:27 2000, beyondsoft <bey...@si...> said: > >beyondsoft> I want to build an UCD-SNMP-4.1.2 without support SNMPV3. > >You can't. The last release without snmpv3 was 3.6.2, and you'd have >to use that. > >beyondsoft> Would you tell me how to build the package? (Pls pay >beyondsoft> attention to that I need build it in 4.1.2). > >However, why would you not want the extra features of SNMPv3? It's >much more secure (or, more appropriately put, it *is* secure). > >-- >Wes Hardaker >Please mail all replies to net...@li... > ______________________________________ =================================================================== ÐÂÀËÃâ·Ñµç×ÓÓÊÏä http://mail.sina.com.cn ÐÂÀËÍƳö°ÂÔ˶ÌÐÅÏ¢ÊÖ»úµã²¥·þÎñ http://sms.sina.com.cn/ |
|
From: Stan B. <st...@aw...> - 2000-11-09 23:27:50
|
On Thu Nov 9 15:29:12 2000 =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= wrote... > >On Thu, Nov 09, 2000 at 03:23:14PM -0500, Stan Brown wrote: >> On Thu Nov 9 13:58:34 2000 =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= wrote... >> > >> >On Thu, Nov 09, 2000 at 12:20:36PM -0500, Stan Brown wrote: >> >> OK, I'm making progress on this, but I'm still a little confused hee. I >> >> have managed to get the CVS sources with the patch compiled and workin >> >> on a Solaris box. However I still don't understnad the results I am >> >> getting. >> >> >> >> Here is what the filesysyems on this machien look like. They are >> >> mirroed concatenated drives BTW >> >> >> >> Filesystem kbytes used avail capacity Mounted on >> >> /dev/md/dsk/d0 35071 18945 12626 61% / >> >> /dev/md/dsk/d4 578455 353161 167454 68% /usr >> >> /dev/md/dsk/d2 26679 6216 17803 26% /var >> >> /dev/md/dsk/d5 3044723 568292 2171961 21% /opt >> >> >> >> Chalenges are fun, but there is a limit to how many my brain can handle >> at once :-) >> >> Here is a bit more inof that may help in the decoding of this: >> >> >> >> Metamirror Submirror Size Device State >> >> d0: d10: 76000 ESP0 / SCSI3 Okay >> d20: 76000 ESP1 / SCSI3 Okay >> d1: d11: 197600 ESP0 / SCSI3 Okay >> d21: 197600 ESP1 / SCSI3 Okay >> d2: d12: 57760 ESP0 / SCSI3 Okay >> d22: 57760 ESP1 / SCSI3 Okay >> d3: d13: 258400 ESP0 / SCSI3 Okay >> d23: 258400 ESP1 / SCSI3 Okay >> d4: d14: 1231200 ESP0 / SCSI3 Okay >> d24: 1231200 ESP1 / SCSI3 Okay >> d5: d15: 6478240 ESP0 / SCSI3 Okay >> d25: 6478240 ESP1 / SCSI3 Okay > >I think this confirms that you should monitor "md0" for /, "md4" for >/usr and so on. Cool. I will give that a try tommorow. Thanks for the hel pn this. -- Stan Brown st...@aw... 843-745-3154 Charleston SC. -- Windows 98: n. useless extension to a minor patch release for 32-bit extensions and a graphical shell for a 16-bit patch to an 8-bit operating system originally coded for a 4-bit microprocessor, written by a 2-bit company that can't stand for 1 bit of competition. - (c) 2000 Stan Brown. Redistribution via the Microsoft Network is prohibited. |
|
From: Stan B. <st...@aw...> - 2000-11-09 23:26:21
|
On Thu Nov 9 18:04:32 2000 Bert Driehuis wrote... > >On Thu, 9 Nov 2000, Stan Brown wrote: > >> That's the good news, now thw bad news. It does not appear that >> seperate read/write counters are maintained. > >The situation is much alike with *BSD. The BSD/OS implementation reports >all I/O's as reads, and returns an error for writes (I'm not sure if >that support actually went in the tree by the way). > So, you read itthesameas I do then? Well, I have not give up on this yet. I'll have another chat with the people at the response center tommorow. It must be possible to do, since they have products that do report the 2 seperately. Thanks for the sanity check. -- Stan Brown st...@aw... 843-745-3154 Charleston SC. -- Windows 98: n. useless extension to a minor patch release for 32-bit extensions and a graphical shell for a 16-bit patch to an 8-bit operating system originally coded for a 4-bit microprocessor, written by a 2-bit company that can't stand for 1 bit of competition. - (c) 2000 Stan Brown. Redistribution via the Microsoft Network is prohibited. |
|
From: Bert D. <dri...@pl...> - 2000-11-09 23:04:35
|
On Thu, 9 Nov 2000, Stan Brown wrote: > That's the good news, now thw bad news. It does not appear that > seperate read/write counters are maintained. The situation is much alike with *BSD. The BSD/OS implementation reports all I/O's as reads, and returns an error for writes (I'm not sure if that support actually went in the tree by the way). It sucks, but what do you do if the OS doesn't instrument it? Cheers, -- Bert Bert Driehuis -- dri...@pl... -- +31-20-3116119 If the only tool you've got is an axe, every problem looks like fun! |
|
From: <uc...@ra...> - 2000-11-09 20:29:24
|
On Thu, Nov 09, 2000 at 03:23:14PM -0500, Stan Brown wrote: > On Thu Nov 9 13:58:34 2000 =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= wrote... > > > >On Thu, Nov 09, 2000 at 12:20:36PM -0500, Stan Brown wrote: > >> OK, I'm making progress on this, but I'm still a little confused hee. I > >> have managed to get the CVS sources with the patch compiled and workin > >> on a Solaris box. However I still don't understnad the results I am > >> getting. > >> > >> Here is what the filesysyems on this machien look like. They are > >> mirroed concatenated drives BTW > >> > >> Filesystem kbytes used avail capacity Mounted on > >> /dev/md/dsk/d0 35071 18945 12626 61% / > >> /dev/md/dsk/d4 578455 353161 167454 68% /usr > >> /dev/md/dsk/d2 26679 6216 17803 26% /var > >> /dev/md/dsk/d5 3044723 568292 2171961 21% /opt > >> > > Chalenges are fun, but there is a limit to how many my brain can handle > at once :-) > > Here is a bit more inof that may help in the decoding of this: > > > > Metamirror Submirror Size Device State > > d0: d10: 76000 ESP0 / SCSI3 Okay > d20: 76000 ESP1 / SCSI3 Okay > d1: d11: 197600 ESP0 / SCSI3 Okay > d21: 197600 ESP1 / SCSI3 Okay > d2: d12: 57760 ESP0 / SCSI3 Okay > d22: 57760 ESP1 / SCSI3 Okay > d3: d13: 258400 ESP0 / SCSI3 Okay > d23: 258400 ESP1 / SCSI3 Okay > d4: d14: 1231200 ESP0 / SCSI3 Okay > d24: 1231200 ESP1 / SCSI3 Okay > d5: d15: 6478240 ESP0 / SCSI3 Okay > d25: 6478240 ESP1 / SCSI3 Okay I think this confirms that you should monitor "md0" for /, "md4" for /usr and so on. -- Ragnar Kjørstad |
|
From: Stan B. <st...@aw...> - 2000-11-09 20:23:28
|
On Thu Nov 9 13:58:34 2000 =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= wrote...
>
>On Thu, Nov 09, 2000 at 12:20:36PM -0500, Stan Brown wrote:
>> OK, I'm making progress on this, but I'm still a little confused hee. I
>> have managed to get the CVS sources with the patch compiled and workin
>> on a Solaris box. However I still don't understnad the results I am
>> getting.
>>
>> Here is what the filesysyems on this machien look like. They are
>> mirroed concatenated drives BTW
>>
>> Filesystem kbytes used avail capacity Mounted on
>> /dev/md/dsk/d0 35071 18945 12626 61% /
>> /dev/md/dsk/d4 578455 353161 167454 68% /usr
>> /dev/md/dsk/d2 26679 6216 17803 26% /var
>> /dev/md/dsk/d5 3044723 568292 2171961 21% /opt
>>
>> Here is what I get when I run snmpwalk on this machine (which of coures
>> translates teh numerical OID's to symbolic).
>>
>> ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.1 = sd6
>> ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.2 = sd3
>> ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.3 = sd10
>> ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.4 = md10
>> ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.5 = md20
>> ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.6 = md0
>> ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.7 = md14
>> ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.8 = md24
>> [cut]
>
>My guess is that there is a md device for each concatenation and a new
>md device for the mirrored device. So if you want to know how much is
>written to the filesystem /, you look at md0. If you want to know about
>/usr you look at md4. You can also find out how much is read to each
>of the mirrors and each of the actual disk by looking at the other
>devices. (don't know how you can find out the md-hierarchie though)
>
>Nah, not if you like challanges! :-)
Chalenges are fun, but there is a limit to how many my brain can handle
at once :-)
Here is a bit more inof that may help in the decoding of this:
Metamirror Submirror Size Device State
d0: d10: 76000 ESP0 / SCSI3 Okay
d20: 76000 ESP1 / SCSI3 Okay
d1: d11: 197600 ESP0 / SCSI3 Okay
d21: 197600 ESP1 / SCSI3 Okay
d2: d12: 57760 ESP0 / SCSI3 Okay
d22: 57760 ESP1 / SCSI3 Okay
d3: d13: 258400 ESP0 / SCSI3 Okay
d23: 258400 ESP1 / SCSI3 Okay
d4: d14: 1231200 ESP0 / SCSI3 Okay
d24: 1231200 ESP1 / SCSI3 Okay
d5: d15: 6478240 ESP0 / SCSI3 Okay
d25: 6478240 ESP1 / SCSI3 Okay
d0: Mirror
Submirror 0: d10
State: Okay
Submirror 1: d20
State: Okay
Pass: 1
Read option: roundrobin (default)
Write option: parallel (default)
Size: 76000 blocks
d10: Submirror of d0
State: Okay
Size: 76000 blocks
Stripe 0:
Device Start Block Dbase State Hot Spare
c0t3d0s0 0 No Okay
d20: Submirror of d0
State: Okay
Size: 76000 blocks
Stripe 0:
Device Start Block Dbase State Hot Spare
c1t3d0s0 0 No Okay
d1: Mirror
Submirror 0: d11
State: Okay
Submirror 1: d21
State: Okay
Pass: 1
Read option: roundrobin (default)
Write option: parallel (default)
Size: 197600 blocks
d11: Submirror of d1
State: Okay
Size: 197600 blocks
Stripe 0:
Device Start Block Dbase State Hot Spare
c0t3d0s1 0 No Okay
d21: Submirror of d1
State: Okay
Size: 197600 blocks
Stripe 0:
Device Start Block Dbase State Hot Spare
c1t3d0s1 0 No Okay
d2: Mirror
Submirror 0: d12
State: Okay
Submirror 1: d22
State: Okay
Pass: 1
Read option: roundrobin (default)
Write option: parallel (default)
Size: 57760 blocks
d12: Submirror of d2
State: Okay
Size: 57760 blocks
Stripe 0:
Device Start Block Dbase State Hot Spare
c0t3d0s4 0 No Okay
d22: Submirror of d2
State: Okay
Size: 57760 blocks
Stripe 0:
Device Start Block Dbase State Hot Spare
c1t3d0s4 0 No Okay
d3: Mirror
Submirror 0: d13
State: Okay
Submirror 1: d23
State: Okay
Pass: 1
Read option: roundrobin (default)
Write option: parallel (default)
Size: 258400 blocks
d13: Submirror of d3
State: Okay
Size: 258400 blocks
Stripe 0:
Device Start Block Dbase State Hot Spare
c0t3d0s5 0 No Okay
d23: Submirror of d3
State: Okay
Size: 258400 blocks
Stripe 0:
Device Start Block Dbase State Hot Spare
c1t3d0s5 0 No Okay
d4: Mirror
Submirror 0: d14
State: Okay
Submirror 1: d24
State: Okay
Pass: 1
Read option: roundrobin (default)
Write option: parallel (default)
Size: 1231200 blocks
d14: Submirror of d4
State: Okay
Size: 1231200 blocks
Stripe 0:
Device Start Block Dbase State Hot Spare
c0t3d0s6 0 No Okay
d24: Submirror of d4
State: Okay
Size: 1231200 blocks
Stripe 0:
Device Start Block Dbase State Hot Spare
c1t3d0s6 0 No Okay
d5: Mirror
Submirror 0: d15
State: Okay
Submirror 1: d25
State: Okay
Pass: 1
Read option: roundrobin (default)
Write option: parallel (default)
Size: 6478240 blocks
d15: Submirror of d5
State: Okay
Size: 6478240 blocks
Stripe 0:
Device Start Block Dbase State Hot Spare
c0t3d0s7 0 No Okay
Stripe 1:
Device Start Block Dbase State Hot Spare
c0t2d0s7 0 No Okay
d25: Submirror of d5
State: Okay
Size: 6478240 blocks
Stripe 0:
Device Start Block Dbase State Hot Spare
c1t3d0s7 0 No Okay
Stripe 1:
Device Start Block Dbase State Hot Spare
c1t2d0s7 0 No Okay
Unfortunately, I still don't see anything that refernces these:
>>
>> ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.1 = sd6
>> ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.2 = sd3
>> ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.3 = sd10
>> ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.4 = md10
>> ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.5 = md20
>> ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.6 = md0
>> ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.7 = md14
>> ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.8 = md24
>> [cut]
--
Stan Brown st...@aw... 843-745-3154
Charleston SC.
--
Windows 98: n.
useless extension to a minor patch release for 32-bit extensions and
a graphical shell for a 16-bit patch to an 8-bit operating system
originally coded for a 4-bit microprocessor, written by a 2-bit
company that can't stand for 1 bit of competition.
-
(c) 2000 Stan Brown. Redistribution via the Microsoft Network is prohibited.
|
|
From: Stan B. <st...@aw...> - 2000-11-09 19:58:34
|
I sepnt a little while looking at how to get the disk I/O statistics
from an HP-UX box today, and the news is partly good partly bad.
First there is a nice set of library functions to obtain kernel data.
They are the pstat-*() family. There is even a pstat_diskinfo(). You
just call it in a ltille while loop starting with index zero, and
incrementing the index untill it returns a value < 0. At that point you
have walked alll the disks on that system.
That's the good news, now thw bad news. It does not appear that
seperate read/write counters are maintained. here is the structure
returned by this call:
struct pst_diskinfo {
long psd_idx; /* Index for further pstat() requests */
struct psdev psd_dev; /* device specification for the disk */
long psd_dktime; /* cumulative milliseconds on the disk */
long psd_dkseek; /* cumulative number of seeks done */
long psd_dkxfer; /* cumulative number of transfers, the
* number include requests with high
* (read/write) and low (ioctl) priorities
*/
long psd_dkwds; /* cumulative number of 64-byte transfers */
float psd_dkmspw; /* OBSOLETE: was milliseconds per word
*/
struct psdev psd_cdev; /* device specification for the raw disk */
/* psd_dev (above) describes the block dev */
struct psdrvnam psd_drv_name; /* driver name */
long psd_token; /* driver's id */
long psd_instance; /* the instance of the device */
struct pshwpath psd_hw_path; /* hardware path */
struct psttime psd_dkwait; /* cumulative time from enqueue to start */
struct psttime psd_dkresp; /* cumulative time from enqueue to done */
long psd_dkcyl_index; /* cylinder number index, used by sadp */
long psd_dkcyl[PS_DK_CYL_SIZE]; /* cylinder number array, used by
* sadp
*/
long psd_dkqlen_curr;/* current queue length */
long psd_dkqlen; /* cummulative queue length */
long psd_dkq_merged; /* cummulative # of transfer would have been
* if some of the requests weren't merged
*/
long psd_dkenq_cnt; /* number of calls to enqueue */
long psd_status; /* 0 = device is closed, 1 = device is open */
};
Looks to me like psd_dkwds will give me the total I/O, but I sure don't
see anything that looks like seperate read & write sattsitics in this
structure. I will keep looking, but I was just wondering if this looked
familiar to anyone else.
--
Stan Brown st...@aw... 843-745-3154
Charleston SC.
--
Windows 98: n.
useless extension to a minor patch release for 32-bit extensions and
a graphical shell for a 16-bit patch to an 8-bit operating system
originally coded for a 4-bit microprocessor, written by a 2-bit
company that can't stand for 1 bit of competition.
-
(c) 2000 Stan Brown. Redistribution via the Microsoft Network is prohibited.
|
|
From: <uc...@ra...> - 2000-11-09 18:58:54
|
On Thu, Nov 09, 2000 at 12:20:36PM -0500, Stan Brown wrote: > OK, I'm making progress on this, but I'm still a little confused hee. I > have managed to get the CVS sources with the patch compiled and workin > on a Solaris box. However I still don't understnad the results I am > getting. > > Here is what the filesysyems on this machien look like. They are > mirroed concatenated drives BTW > > Filesystem kbytes used avail capacity Mounted on > /dev/md/dsk/d0 35071 18945 12626 61% / > /dev/md/dsk/d4 578455 353161 167454 68% /usr > /dev/md/dsk/d2 26679 6216 17803 26% /var > /dev/md/dsk/d5 3044723 568292 2171961 21% /opt > > Here is what I get when I run snmpwalk on this machine (which of coures > translates teh numerical OID's to symbolic). > > ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.1 = sd6 > ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.2 = sd3 > ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.3 = sd10 > ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.4 = md10 > ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.5 = md20 > ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.6 = md0 > ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.7 = md14 > ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.8 = md24 > [cut] My guess is that there is a md device for each concatenation and a new md device for the mirrored device. So if you want to know how much is written to the filesystem /, you look at md0. If you want to know about /usr you look at md4. You can also find out how much is read to each of the mirrors and each of the actual disk by looking at the other devices. (don't know how you can find out the md-hierarchie though) > Here is what I get when I run snmpwalk from another machien, so that I > can see the numeric OID's, which I need to put into the mrtg config > file. If you want the strings, just copy the MIB file over, and tell snmpwalk to load it. > My suspicion is thta I picked a poor box to test on. Perhaps I should > have picked a box with a one to one maping of disk devices to > filesystems? Nah, not if you like challanges! :-) > Could someone educate me a bit here? I don't know how md on Solaris works, but my guess is it's not too different from md on linux.. You can check that you have the right devices by actually reading or writing to one of the filesystems and see that the correct data is updated in the deamon. (be awere that there is some caching though). -- Ragnar Kjørstad |
|
From: Stan B. <st...@aw...> - 2000-11-09 17:20:44
|
OK, I'm making progress on this, but I'm still a little confused hee. I have managed to get the CVS sources with the patch compiled and workin on a Solaris box. However I still don't understnad the results I am getting. Here is what the filesysyems on this machien look like. They are mirroed concatenated drives BTW Filesystem kbytes used avail capacity Mounted on /dev/md/dsk/d0 35071 18945 12626 61% / /dev/md/dsk/d4 578455 353161 167454 68% /usr /dev/md/dsk/d2 26679 6216 17803 26% /var /dev/md/dsk/d5 3044723 568292 2171961 21% /opt Here is what I get when I run snmpwalk on this machine (which of coures translates teh numerical OID's to symbolic). enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOIndex.1 = 1 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOIndex.2 = 2 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOIndex.3 = 3 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOIndex.4 = 4 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOIndex.5 = 5 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOIndex.6 = 6 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOIndex.7 = 7 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOIndex.8 = 8 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOIndex.9 = 9 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOIndex.10 = 10 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOIndex.11 = 11 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOIndex.12 = 12 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOIndex.13 = 13 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOIndex.14 = 14 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOIndex.15 = 15 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOIndex.16 = 16 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOIndex.17 = 17 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOIndex.18 = 18 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOIndex.19 = 19 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOIndex.20 = 20 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.1 = sd6 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.2 = sd3 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.3 = sd10 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.4 = md10 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.5 = md20 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.6 = md0 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.7 = md14 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.8 = md24 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.9 = md4 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.10 = md11 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.11 = md21 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.12 = md1 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.13 = md12 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.14 = md22 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.15 = md2 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.16 = sd2 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.17 = md15 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.18 = sd9 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.19 = md25 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIODevice.20 = md5 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONRead.1 = 0 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONRead.2 = 483138560 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONRead.3 = 485388288 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONRead.4 = 32005632 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONRead.5 = 32523264 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONRead.6 = 64528896 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONRead.7 = 310504448 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONRead.8 = 312832512 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONRead.9 = 623336960 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONRead.10 = 0 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONRead.11 = 4096 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONRead.12 = 4096 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONRead.13 = 18654720 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONRead.14 = 19080704 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONRead.15 = 37735424 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONRead.16 = 702636544 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONRead.17 = 823778816 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONRead.18 = 703022080 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONRead.19 = 823170560 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONRead.20 = 1646949376 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONWritten.1 = 0 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONWritten.2 = 1389597184 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONWritten.3 = 1115838464 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONWritten.4 = 176157696 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONWritten.5 = 176125440 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONWritten.6 = 179121152 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONWritten.7 = 584675840 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONWritten.8 = 584629760 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONWritten.9 = 590845952 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONWritten.10 = 1540096 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONWritten.11 = 1536000 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONWritten.12 = 1540096 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONWritten.13 = 183229440 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONWritten.14 = 182998016 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONWritten.15 = 183713792 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONWritten.16 = 1219787776 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONWritten.17 = 1310242816 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONWritten.18 = 1219832832 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONWritten.19 = 1310310400 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIONWritten.20 = 1310971904 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOReads.1 = 0 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOReads.2 = 92832 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOReads.3 = 92771 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOReads.4 = 8582 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOReads.5 = 8583 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOReads.6 = 17165 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOReads.7 = 53889 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOReads.8 = 53890 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOReads.9 = 107779 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOReads.10 = 0 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOReads.11 = 1 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOReads.12 = 1 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOReads.13 = 7312 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOReads.14 = 7312 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOReads.15 = 14624 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOReads.16 = 98338 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOReads.17 = 120940 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOReads.18 = 98389 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOReads.19 = 120940 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOReads.20 = 241880 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOWrites.1 = 1 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOWrites.2 = 694659 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOWrites.3 = 160539 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOWrites.4 = 28931 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOWrites.5 = 28931 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOWrites.6 = 29534 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOWrites.7 = 70357 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOWrites.8 = 70356 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOWrites.9 = 70962 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOWrites.10 = 29 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOWrites.11 = 28 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOWrites.12 = 29 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOWrites.13 = 31077 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOWrites.14 = 31077 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOWrites.15 = 31197 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOWrites.16 = 207451 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOWrites.17 = 228600 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOWrites.18 = 207448 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOWrites.19 = 228600 enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOWrites.20 = 228696 snmpwalk waterap public .1.3.6.1.4.1.2021.13.15 Here is what I get when I run snmpwalk from another machien, so that I can see the numeric OID's, which I need to put into the mrtg config file. enterprises.ucdavis.ucdExperimental.15.1.1.1.1 = 1 enterprises.ucdavis.ucdExperimental.15.1.1.1.2 = 2 enterprises.ucdavis.ucdExperimental.15.1.1.1.3 = 3 enterprises.ucdavis.ucdExperimental.15.1.1.1.4 = 4 enterprises.ucdavis.ucdExperimental.15.1.1.1.5 = 5 enterprises.ucdavis.ucdExperimental.15.1.1.1.6 = 6 enterprises.ucdavis.ucdExperimental.15.1.1.1.7 = 7 enterprises.ucdavis.ucdExperimental.15.1.1.1.8 = 8 enterprises.ucdavis.ucdExperimental.15.1.1.1.9 = 9 enterprises.ucdavis.ucdExperimental.15.1.1.1.10 = 10 enterprises.ucdavis.ucdExperimental.15.1.1.1.11 = 11 enterprises.ucdavis.ucdExperimental.15.1.1.1.12 = 12 enterprises.ucdavis.ucdExperimental.15.1.1.1.13 = 13 enterprises.ucdavis.ucdExperimental.15.1.1.1.14 = 14 enterprises.ucdavis.ucdExperimental.15.1.1.1.15 = 15 enterprises.ucdavis.ucdExperimental.15.1.1.1.16 = 16 enterprises.ucdavis.ucdExperimental.15.1.1.1.17 = 17 enterprises.ucdavis.ucdExperimental.15.1.1.1.18 = 18 enterprises.ucdavis.ucdExperimental.15.1.1.1.19 = 19 enterprises.ucdavis.ucdExperimental.15.1.1.1.20 = 20 enterprises.ucdavis.ucdExperimental.15.1.1.2.1 = "sd6" Hex: 73 64 36 enterprises.ucdavis.ucdExperimental.15.1.1.2.2 = "sd3" Hex: 73 64 33 enterprises.ucdavis.ucdExperimental.15.1.1.2.3 = "sd10" Hex: 73 64 31 30 enterprises.ucdavis.ucdExperimental.15.1.1.2.4 = "md10" Hex: 6D 64 31 30 enterprises.ucdavis.ucdExperimental.15.1.1.2.5 = "md20" Hex: 6D 64 32 30 enterprises.ucdavis.ucdExperimental.15.1.1.2.6 = "md0" Hex: 6D 64 30 enterprises.ucdavis.ucdExperimental.15.1.1.2.7 = "md14" Hex: 6D 64 31 34 enterprises.ucdavis.ucdExperimental.15.1.1.2.8 = "md24" Hex: 6D 64 32 34 enterprises.ucdavis.ucdExperimental.15.1.1.2.9 = "md4" Hex: 6D 64 34 enterprises.ucdavis.ucdExperimental.15.1.1.2.10 = "md11" Hex: 6D 64 31 31 enterprises.ucdavis.ucdExperimental.15.1.1.2.11 = "md21" Hex: 6D 64 32 31 enterprises.ucdavis.ucdExperimental.15.1.1.2.12 = "md1" Hex: 6D 64 31 enterprises.ucdavis.ucdExperimental.15.1.1.2.13 = "md12" Hex: 6D 64 31 32 enterprises.ucdavis.ucdExperimental.15.1.1.2.14 = "md22" Hex: 6D 64 32 32 enterprises.ucdavis.ucdExperimental.15.1.1.2.15 = "md2" Hex: 6D 64 32 enterprises.ucdavis.ucdExperimental.15.1.1.2.16 = "sd2" Hex: 73 64 32 enterprises.ucdavis.ucdExperimental.15.1.1.2.17 = "md15" Hex: 6D 64 31 35 enterprises.ucdavis.ucdExperimental.15.1.1.2.18 = "sd9" Hex: 73 64 39 enterprises.ucdavis.ucdExperimental.15.1.1.2.19 = "md25" Hex: 6D 64 32 35 enterprises.ucdavis.ucdExperimental.15.1.1.2.20 = "md5" Hex: 6D 64 35 enterprises.ucdavis.ucdExperimental.15.1.1.3.1 = 0 enterprises.ucdavis.ucdExperimental.15.1.1.3.2 = 483110912 enterprises.ucdavis.ucdExperimental.15.1.1.3.3 = 485355520 enterprises.ucdavis.ucdExperimental.15.1.1.3.4 = 31994368 enterprises.ucdavis.ucdExperimental.15.1.1.3.5 = 32498688 enterprises.ucdavis.ucdExperimental.15.1.1.3.6 = 64493056 enterprises.ucdavis.ucdExperimental.15.1.1.3.7 = 310496256 enterprises.ucdavis.ucdExperimental.15.1.1.3.8 = 312824320 enterprises.ucdavis.ucdExperimental.15.1.1.3.9 = 623320576 enterprises.ucdavis.ucdExperimental.15.1.1.3.10 = 0 enterprises.ucdavis.ucdExperimental.15.1.1.3.11 = 4096 enterprises.ucdavis.ucdExperimental.15.1.1.3.12 = 4096 enterprises.ucdavis.ucdExperimental.15.1.1.3.13 = 18646528 enterprises.ucdavis.ucdExperimental.15.1.1.3.14 = 19080704 enterprises.ucdavis.ucdExperimental.15.1.1.3.15 = 37727232 enterprises.ucdavis.ucdExperimental.15.1.1.3.16 = 702603776 enterprises.ucdavis.ucdExperimental.15.1.1.3.17 = 823746048 enterprises.ucdavis.ucdExperimental.15.1.1.3.18 = 703006720 enterprises.ucdavis.ucdExperimental.15.1.1.3.19 = 823155200 enterprises.ucdavis.ucdExperimental.15.1.1.3.20 = 1646901248 enterprises.ucdavis.ucdExperimental.15.1.1.4.1 = 0 enterprises.ucdavis.ucdExperimental.15.1.1.4.2 = 1389133312 enterprises.ucdavis.ucdExperimental.15.1.1.4.3 = 1115442176 enterprises.ucdavis.ucdExperimental.15.1.1.4.4 = 175941632 enterprises.ucdavis.ucdExperimental.15.1.1.4.5 = 175909376 enterprises.ucdavis.ucdExperimental.15.1.1.4.6 = 178905088 enterprises.ucdavis.ucdExperimental.15.1.1.4.7 = 584516096 enterprises.ucdavis.ucdExperimental.15.1.1.4.8 = 584470016 enterprises.ucdavis.ucdExperimental.15.1.1.4.9 = 590686208 enterprises.ucdavis.ucdExperimental.15.1.1.4.10 = 1540096 enterprises.ucdavis.ucdExperimental.15.1.1.4.11 = 1536000 enterprises.ucdavis.ucdExperimental.15.1.1.4.12 = 1540096 enterprises.ucdavis.ucdExperimental.15.1.1.4.13 = 183219200 enterprises.ucdavis.ucdExperimental.15.1.1.4.14 = 182987776 enterprises.ucdavis.ucdExperimental.15.1.1.4.15 = 183703552 enterprises.ucdavis.ucdExperimental.15.1.1.4.16 = 1219639296 enterprises.ucdavis.ucdExperimental.15.1.1.4.17 = 1310084096 enterprises.ucdavis.ucdExperimental.15.1.1.4.18 = 1219684352 enterprises.ucdavis.ucdExperimental.15.1.1.4.19 = 1310151680 enterprises.ucdavis.ucdExperimental.15.1.1.4.20 = 1310813184 enterprises.ucdavis.ucdExperimental.15.1.1.5.1 = 0 enterprises.ucdavis.ucdExperimental.15.1.1.5.2 = 92828 enterprises.ucdavis.ucdExperimental.15.1.1.5.3 = 92767 enterprises.ucdavis.ucdExperimental.15.1.1.5.4 = 8580 enterprises.ucdavis.ucdExperimental.15.1.1.5.5 = 8580 enterprises.ucdavis.ucdExperimental.15.1.1.5.6 = 17160 enterprises.ucdavis.ucdExperimental.15.1.1.5.7 = 53888 enterprises.ucdavis.ucdExperimental.15.1.1.5.8 = 53889 enterprises.ucdavis.ucdExperimental.15.1.1.5.9 = 107777 enterprises.ucdavis.ucdExperimental.15.1.1.5.10 = 0 enterprises.ucdavis.ucdExperimental.15.1.1.5.11 = 1 enterprises.ucdavis.ucdExperimental.15.1.1.5.12 = 1 enterprises.ucdavis.ucdExperimental.15.1.1.5.13 = 7311 enterprises.ucdavis.ucdExperimental.15.1.1.5.14 = 7312 enterprises.ucdavis.ucdExperimental.15.1.1.5.15 = 14623 enterprises.ucdavis.ucdExperimental.15.1.1.5.16 = 98334 enterprises.ucdavis.ucdExperimental.15.1.1.5.17 = 120936 enterprises.ucdavis.ucdExperimental.15.1.1.5.18 = 98385 enterprises.ucdavis.ucdExperimental.15.1.1.5.19 = 120936 enterprises.ucdavis.ucdExperimental.15.1.1.5.20 = 241872 enterprises.ucdavis.ucdExperimental.15.1.1.6.1 = 1 enterprises.ucdavis.ucdExperimental.15.1.1.6.2 = 694457 enterprises.ucdavis.ucdExperimental.15.1.1.6.3 = 160473 enterprises.ucdavis.ucdExperimental.15.1.1.6.4 = 28895 enterprises.ucdavis.ucdExperimental.15.1.1.6.5 = 28895 enterprises.ucdavis.ucdExperimental.15.1.1.6.6 = 29498 enterprises.ucdavis.ucdExperimental.15.1.1.6.7 = 70336 enterprises.ucdavis.ucdExperimental.15.1.1.6.8 = 70335 enterprises.ucdavis.ucdExperimental.15.1.1.6.9 = 70941 enterprises.ucdavis.ucdExperimental.15.1.1.6.10 = 29 enterprises.ucdavis.ucdExperimental.15.1.1.6.11 = 28 enterprises.ucdavis.ucdExperimental.15.1.1.6.12 = 29 enterprises.ucdavis.ucdExperimental.15.1.1.6.13 = 31075 enterprises.ucdavis.ucdExperimental.15.1.1.6.14 = 31075 enterprises.ucdavis.ucdExperimental.15.1.1.6.15 = 31195 enterprises.ucdavis.ucdExperimental.15.1.1.6.16 = 207421 enterprises.ucdavis.ucdExperimental.15.1.1.6.17 = 228567 enterprises.ucdavis.ucdExperimental.15.1.1.6.18 = 207418 enterprises.ucdavis.ucdExperimental.15.1.1.6.19 = 228567 enterprises.ucdavis.ucdExperimental.15.1.1.6.20 = 228663 My suspicion is thta I picked a poor box to test on. Perhaps I should have picked a box with a one to one maping of disk devices to filesystems? Could someone educate me a bit here? Thanks. -- Stan Brown st...@aw... 843-745-3154 Charleston SC. -- Windows 98: n. useless extension to a minor patch release for 32-bit extensions and a graphical shell for a 16-bit patch to an 8-bit operating system originally coded for a 4-bit microprocessor, written by a 2-bit company that can't stand for 1 bit of competition. - (c) 2000 Stan Brown. Redistribution via the Microsoft Network is prohibited. |
|
From: RADMAN S. <Ste...@CT...> - 2000-11-09 13:33:56
|
Since my last mail was a little bit too large :) I'll just include the
essentials this time.
ENVIRONMENT:
SunOS idc009 5.6 Generic_105181-17 sun4u sparc SUNW,Ultra-1
gcc version 2.95.2 19991024 (release)
BUILD:
make distclean
configure --with-defaults
make
make test
RESULTS:
- tests all failed with coredump (Segmentation Fault or Bus Error).
- same result when I run the tests as root
- did further testing using the snmptranslate binary from the sourcetree
(see below)
DEBUG:
----------------------------------------------------------------------------
----
IDCsoh@idc009:work/ucd-snmp-4.2.pre1 export
LD_LIBRARY_PATH=`pwd`/snmplib/.libs
IDCsoh@idc009:work/ucd-snmp-4.2.pre1 export MIBDIRS=`pwd`/mibs
IDCsoh@idc009:work/ucd-snmp-4.2.pre1 cd apps/.libs
IDCsoh@idc009:work/ucd-snmp-4.2.pre1 ./snmptranslate system
Segmentation Fault(coredump)
IDCsoh@idc009:work/ucd-snmp-4.2.pre1 ./snmptranslate .1
.1
IDCsoh@idc009:work/ucd-snmp-4.2.pre1 ./snmptranslate -On .1
.iso
IDCsoh@idc009:work/ucd-snmp-4.2.pre1 ./snmptranslate -On system
Segmentation Fault(coredump)
IDCsoh@idc009:work/ucd-snmp-4.2.pre1 gdb ./snmptranslate core
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2"...
Core was generated by `./snmptranslate -On system'.
Program terminated with signal 11, Segmentation Fault.
Reading symbols from
/ctbto/idc/infra/ho/source/build/IDCsoh/work/ucd-snmp-4.2.pre1/snmplib/.libs
/libsnmp-0.4.2.0.1.so...done.
Reading symbols from /usr/lib/libdl.so.1...done.
Reading symbols from /usr/lib/libkvm.so.1...done.
Reading symbols from /usr/lib/libkstat.so.1...done.
Reading symbols from /usr/lib/libm.so.1...done.
Reading symbols from /usr/lib/libelf.so.1...done.
Reading symbols from /usr/lib/libnsl.so.1...done.
Reading symbols from /usr/lib/libsocket.so.1...done.
Reading symbols from /usr/lib/libc.so.1...done.
Reading symbols from /usr/lib/libmp.so.2...done.
Reading symbols from /usr/platform/SUNW,Ultra-1/lib/libc_psr.so.1...done.
Reading symbols from /usr/lib/nss_nisplus.so.1...done.
Reading symbols from /usr/lib/libdoor.so.1...done.
Reading symbols from /usr/lib/nss_files.so.1...done.
#0 0xef4a4734 in strlen () from /usr/lib/libc.so.1
(gdb)
(gdb) bt
#0 0xef4a4734 in strlen () from /usr/lib/libc.so.1
#1 0xef4da65c in _doprnt () from /usr/lib/libc.so.1
#2 0xef4e3834 in sprintf () from /usr/lib/libc.so.1
#3 0xef734990 in _add_strings_to_oid (tp=0x321e0, cp=0x53b30 "/opt/IDCsoh",
objid=0xeffff430,
objidlen=0xeffff424, maxlen=128) at mib.c:2392
#4 0xef7322b8 in read_objid (input=0xefffe9b0 "/opt/IDCsoh.system",
output=0xeffff430,
out_len=0xeffff424) at mib.c:1386
#5 0x11b58 in main (argc=3, argv=0xeffff6a4) at snmptranslate.c:335
(gdb)
-------------------
CONCLUSION:
snmplib trys to prepend $PREFIX to the oids but in my case this is not meant
to be an OID prefix but the path prefix I'm using during build.
Seems that snmplib is getting confused by the "/"s in there and dumps core.
unset PREFIX and ran the same tests again as root - SUCCEEDED.
Stefan Radman
Network Specialist
CTBTO/IDC
Email: mailto://Ste...@ct...
Phone: +43 (1) 26030-6182
Fax: +43 (1) 260308-6182
|
|
From: Stan B. <st...@aw...> - 2000-11-09 11:26:58
|
On Thu Nov 9 01:45:21 2000 Wes Hardaker wrote... > >>>>>> On Thu, 9 Nov 2000 02:18:08 +0100, Ragnar Kjørstad <uc...@ra...> said: > >The table and entry definitions are required to be SNMP compliant with >the way the data is structured. Patch below (thanks for offering to >create one, by the way). > Thanks, I will take aloook at what it will take to add HP-UX 10.20 support for this today. -- Stan Brown st...@aw... 843-745-3154 Charleston SC. -- Windows 98: n. useless extension to a minor patch release for 32-bit extensions and a graphical shell for a 16-bit patch to an 8-bit operating system originally coded for a 4-bit microprocessor, written by a 2-bit company that can't stand for 1 bit of competition. - (c) 2000 Stan Brown. Redistribution via the Microsoft Network is prohibited. |
|
From: Wes H. <wjh...@uc...> - 2000-11-09 06:45:39
|
>>>>> On Thu, 9 Nov 2000 02:18:08 +0100, Ragnar Kjørstad <uc...@ra...> said:
>> >No, this is a bug in the module.
>> >Apperently the agent-code and the MIB got out of sync when the code was
>> >moved into ucdExperimental.
It seems a bit odd that the table/entry suffix was dropped when it was
moved...
>> >My code includes:
>> >oid diskio_variables_oid[] = { 1,3,6,1,4,1,2021,13,15,1,1 };
That should be correct.
rstad> In addition to the variable itself, I think there is a variable
rstad> containing the length too, so if you add ",1,1" you probably
rstad> have to add 2 to that constant.
There isn't a length variable, its determined automatically at
compile-time by the REGISTER_MIB macro.
rstad> So Wes, what's do you want?
rstad> ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOIndex
rstad> or
rstad> ucdExperimental.ucdDiskIOMIB.diskIOIndex
rstad> ?
rstad> Personally I don't see the point of diskIOTable and
rstad> diskIOEntry, and I think it whould be "ucdDiskIO" not
rstad> "ucdDiskIOMIB". Anyone?
The table and entry definitions are required to be SNMP compliant with
the way the data is structured. Patch below (thanks for offering to
create one, by the way).
--
Wes Hardaker
Please mail all replies to net...@li...
Index: diskio.c
===================================================================
RCS file: /cvsroot/net-snmp/net-snmp/agent/mibgroup/ucd-snmp/diskio.c,v
retrieving revision 1.3
diff -u -r1.3 diskio.c
--- diskio.c 2000/05/05 16:56:55 1.3
+++ diskio.c 2000/11/09 06:44:48
@@ -78,7 +78,7 @@
/* Define the OID pointer to the top of the mib tree that we're
registering underneath. */
- oid diskio_variables_oid[] = { 1,3,6,1,4,1,2021,13,15 };
+ oid diskio_variables_oid[] = { 1,3,6,1,4,1,2021,13,15,1,1 };
/* register ourselves with the agent to handle our mib tree
|
|
From: N.Tanaka <nob...@ro...> - 2000-11-09 06:03:57
|
Hello. I have a question about implementaion of net-snmp-4.1.2'
s smux.
I have made smux-peer program and be trying to communicate to
snmpd from net-snmp-4.1.2. When snmpd received setRequest from
manager, I could see 2 getRequests from snmpd and 1 setRequest
from snmpd like below.
smux-peer snmpd manager
----+---- --+-- ---+---
| | |
| |<---setRequest--- |
|<---getReq------ | |
| --------------->| |
| | |
|<---setReq------ | |
| --------------->| |
| | |
|<---getReq------ | |
| --------------->| |
| | |
|<---SOut-------- | |
| --------------->| |
| | ---getResponse-->|
| | |
(1) Is this normal ? (I have thought only one setRequest from
snmpd would apper in this situation ).
(2) This seems to be kind of much prudent, why ?
(3) Can I customize to reduce message ?
or which part should I modify in source codes.
Thanks in advance.
--
Nobuaki Tanaka
- NTT SOFT Co, Musashino Tokyo Japan -
+81-422-51-4153 (Tel)
+81-422-51-6261 (Fax)
|
|
From: <uc...@ra...> - 2000-11-09 01:41:31
|
On Wed, Nov 08, 2000 at 08:31:43PM -0500, Stan Brown wrote: > >I'll happily provide a patch once I know what to fix, the MIB or the > >C-code, but I'm too lacy to do it twice :) > >So Wes, what's do you want? > >ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOIndex > >or > >ucdExperimental.ucdDiskIOMIB.diskIOIndex > >? > > > >Personally I don't see the point of diskIOTable and diskIOEntry, and I > >think it whould be "ucdDiskIO" not "ucdDiskIOMIB". Anyone? > >I'm way to unfamiliar wiht this to have an opinion. But could we please get a >concensus on this? So am I :-) -- Ragnar Kjørstad |
|
From: Stan B. <st...@aw...> - 2000-11-09 01:31:53
|
On Wed Nov 8 20:18:08 2000 =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= wrote... > > >I'll happily provide a patch once I know what to fix, the MIB or the >C-code, but I'm too lacy to do it twice :) >So Wes, what's do you want? >ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOIndex >or >ucdExperimental.ucdDiskIOMIB.diskIOIndex >? > >Personally I don't see the point of diskIOTable and diskIOEntry, and I >think it whould be "ucdDiskIO" not "ucdDiskIOMIB". Anyone? I'm way to unfamiliar wiht this to have an opinion. But could we please get a concensus on this? I intend to satrt looking at extending this functionality to some other OS'es in the near term future. Thanks for the education. -- Stan Brown st...@aw... 843-745-3154 Charleston SC. -- Windows 98: n. useless extension to a minor patch release for 32-bit extensions and a graphical shell for a 16-bit patch to an 8-bit operating system originally coded for a 4-bit microprocessor, written by a 2-bit company that can't stand for 1 bit of competition. - (c) 2000 Stan Brown. Redistribution via the Microsoft Network is prohibited. |
|
From: <uc...@ra...> - 2000-11-09 01:18:23
|
On Wed, Nov 08, 2000 at 08:04:33PM -0500, Stan Brown wrote:
> >On Wed, Nov 08, 2000 at 12:44:07PM -0500, Stan Brown wrote:
> >> snmpwalk localhost public .1.3.6.1.4.1.2021 | grep diskIOTable
> >> enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry = 1
> >> enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.2 = 2
> >> [ cut ]
> >>
> >> Is it possible I still don't have something configured corectly on this
> >> machine?
> >
> >No, this is a bug in the module.
> >Apperently the agent-code and the MIB got out of sync when the code was
> >moved into ucdExperimental.
> >
> >My code includes:
> >oid diskio_variables_oid[] = { 1,3,6,1,4,1,2021,13,15,1,1 };
> >
> >but the code in the cvs three includes:
> >oid diskio_variables_oid[] = { 1,3,6,1,4,1,2021,13,15 };
> >
> >
> >I suppose the correct fix is to update the mib though? I assume the
> >agent-code was changed on purpose....
>
> Man, you are _way_ over my head here.
Sorry about that.
> Please tell me where in teh source tree you are loooking. I suppose I better
> figure this out, if I'm going to help get some more pieces of this working.
The diskio_variables_oid[] is set in
net-snmp/agent/mibgroup/ucd-snmp/diskio.c
In addition to the variable itself, I think there is a variable
containing the length too, so if you add ",1,1" you probably have to add
2 to that constant.
But, I assume the OID was changed for a reason, and Wes (or whoever it
was) like the new OID better.... If so, the correct fix is to update the
MIB (the file that maps numeric OIDs to strings) to reflect the new OID.
This data is stored in "net-snmp/mibs/UCD-DISKIO.MIB.txt" (by memory,
maybe not 100%). It's harder to explain how to fix this, but it includes
removing 2 "nodes" and updating the child-nodes to connect to the
correct parent. Yes, I know that's a lousy explanation.
I'll happily provide a patch once I know what to fix, the MIB or the
C-code, but I'm too lacy to do it twice :)
So Wes, what's do you want?
ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry.diskIOIndex
or
ucdExperimental.ucdDiskIOMIB.diskIOIndex
?
Personally I don't see the point of diskIOTable and diskIOEntry, and I
think it whould be "ucdDiskIO" not "ucdDiskIOMIB". Anyone?
--
Ragnar Kjørstad
|
|
From: Stan B. <st...@aw...> - 2000-11-09 01:04:45
|
On Wed Nov 8 16:21:05 2000 =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= wrote...
>
>On Wed, Nov 08, 2000 at 12:44:07PM -0500, Stan Brown wrote:
>> snmpwalk localhost public .1.3.6.1.4.1.2021 | grep diskIOTable
>> enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry = 1
>> enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.2 = 2
>> [ cut ]
>>
>> Is it possible I still don't have something configured corectly on this
>> machine?
>
>No, this is a bug in the module.
>Apperently the agent-code and the MIB got out of sync when the code was
>moved into ucdExperimental.
>
>My code includes:
>oid diskio_variables_oid[] = { 1,3,6,1,4,1,2021,13,15,1,1 };
>
>but the code in the cvs three includes:
>oid diskio_variables_oid[] = { 1,3,6,1,4,1,2021,13,15 };
>
>
>I suppose the correct fix is to update the mib though? I assume the
>agent-code was changed on purpose....
Man, you are _way_ over my head here.
Please tell me where in teh source tree you are loooking. I suppose I better
figure this out, if I'm going to help get some more pieces of this working.
--
Stan Brown st...@aw... 843-745-3154
Charleston SC.
--
Windows 98: n.
useless extension to a minor patch release for 32-bit extensions and
a graphical shell for a 16-bit patch to an 8-bit operating system
originally coded for a 4-bit microprocessor, written by a 2-bit
company that can't stand for 1 bit of competition.
-
(c) 2000 Stan Brown. Redistribution via the Microsoft Network is prohibited.
|
|
From: <uc...@ra...> - 2000-11-08 21:21:16
|
On Wed, Nov 08, 2000 at 12:44:07PM -0500, Stan Brown wrote:
> snmpwalk localhost public .1.3.6.1.4.1.2021 | grep diskIOTable
> enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.diskIOEntry = 1
> enterprises.ucdavis.ucdExperimental.ucdDiskIOMIB.diskIOTable.2 = 2
> [ cut ]
>
> Is it possible I still don't have something configured corectly on this
> machine?
No, this is a bug in the module.
Apperently the agent-code and the MIB got out of sync when the code was
moved into ucdExperimental.
My code includes:
oid diskio_variables_oid[] = { 1,3,6,1,4,1,2021,13,15,1,1 };
but the code in the cvs three includes:
oid diskio_variables_oid[] = { 1,3,6,1,4,1,2021,13,15 };
I suppose the correct fix is to update the mib though? I assume the
agent-code was changed on purpose....
--
Ragnar Kjørstad
|
475 messages has been excluded from this view by a project administrator.
