[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.

Option three is an important sematic. To what applications do you refer?

> [...]
> 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 as long as do nothing to tie the pm module to this other work, I am OK.
> /js
> -- 
> 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/>


Jon Saperia		     saperia@jdscons.com
			     Phone: 617-744-1079
			     Fax:   617-249-0874