We have a device that will be using net-snmp as our SNMP stack. The device uses RAM for the filesystem, and uses flash for persistent storage. We need to support SNMP-TARGET-MIB, SNMP-NOTIFICATION-MIB, etc. that have read-write OIDs. Happily, net-snmp already implements these MIBs, including writing them out to the persistent configuration file.
One of the things we are trying to do is minimize the number of writes to flash to extend the life of the device. We have a couple of choices with the persistent configuration files, namely: 1) Leave the persistent config files in the RAM filesystem (e.g., /var/snmp) and copy it to and from flash on startup and shutdown respectively of the device. The obvious problem with this approach is that if the device crashes or shuts down abnormally, the files may not get copied off and thus data may be lost. 2) Put the persistent config files directly on flash (either ./configure it to point to our flash filesystem or symlink /var/snmp to somewhere on flash) and trust that we won't be actually writing to the files that often. The drawback to this approach is that we may be writing more often than we'd really like. From what I've read so far in the code, it looks like MIB implementation modules are expected to register a callback handler (SNMP_CALLBACK_STORE_DATA) to actually do the storage of data when the application decides to do it. Specifically, when snmp_api.c::snmp_store() is called, which for snmpd seems to be: 1. When the agent starts up. 2. When the agent shuts down. 3. When the ifTable and ifXTable are modified. 4. When snmpNotifyTable is modified. Each time snmp_store() is called, it calls (for that file type): - snmp_save_persistent() - snmp_call_callbacks() - snmp_clean_persistent() snmp_save_persistent() renames the existing configuration file as a backup, and snmp_clean_persistent() unlinks the backup. snmp_call_callbacks() does the obvious thing: all registered SNMP_CALLBACK_STORE_DATA functions are called. Each store data callback in snmpd does more or less the following: - construct a line of configuration data to store - write that configuration using snmpd_store_config() - repeat till all lines are written out. From snmpd_store_config(), there a call chain that eventually terminates in read_config_store() which opens the persistent config file in append mode, writes the line, and then closes the file. That strikes me as potentially an awful lot of writes to flash depending on how much data is being updated directly in the MIBS. From the above analysis, I'm inclined to take approach 1 (copy the persistent file to and from flash on startup and shutdown). Have I missed anything? Does anyone else have a different opinion? -- Glenn McAllister <[EMAIL PROTECTED]> +1 416 348 1594 SOMA Networks, Inc. http://www.somanetworks.com/ +1 416 977 1414 ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
