[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: snmpconf PM MIB Issue #9

>>>>> Steve Waldbusser writes:

Steve> I believe Juergen's proposal gives the flexibility that the
Steve> write can be done early but it must be complete by the time the
Steve> button push is complete in the snmpStorage MIB. In other words,
Steve> it's like syncing a file system. Prior to the sync the
Steve> application knows that things *might* have been written to disk
Steve> but there is no guarantee. The sync can't complete until any
Steve> unwritten data is written. After the sync the app has a
Steve> guarantee that the data is written.

Very good summary. Perhaps we should really use the term sync to make
things easier to understand.

Steve> This adapts to multiple strategies, including: 1) Write to
Steve> nvram immediately on activating the target row (sync is a
Steve> no-op) 2) Every N seconds, look for unwritten rows and write
Steve> them (sync only writes rows that have been modified since last
Steve> interval) 3) Delay writes until sync button is pushed

Option 3) is a bit problematic with the current StorageType. Right
now, applications assume that setting the StorageType to nonVolatile
is enough to put the configuration information into stable storage,
even though it is right now implementation specific when this actually
happens. But it should happen at some point in time. So only relying
on the sync button might confuse existing applications that do not
know about sync buttons. So if 3) is an option we want, then we
probably need to have a new StorageType kind of TC.


Steve> My main question is, given that there's no way for Juergen's
Steve> proposal to be standardized before the PM MIB, how do we
Steve> proceed now? We could:

Steve> 1) Do nothing and wait for the storage-type MIB to clarify the
Steve> PM MIB in the same way as it will clarify all other existing
Steve> use of storageType.  (This doesn't add any dependence on the
Steve> completion of the storage type MIB).

Steve> 2) Add a scalar to the PM MIB that writes all nonVolatile
Steve> entries

If we can get agreement on the storage type MIB approach quickly (and
the problem is IMHO not really that complicated), then option 1) seems
most reasonable in the longer term perspective. Even if this WG
decides to go with the scalar approach, it would be desirable to
define a generic TC which defines all the semantics needed for such
a sync button so that it can be reused.


Juergen Schoenwaelder      Technical University Braunschweig
<schoenw@ibr.cs.tu-bs.de>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>