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

Re: snmpconf PM MIB Issue #9





Juergen Schoenwaelder wrote:
> 
> >>>>> 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.

Good point. 

BTW, I'm not pushing for #3 and I've never heard that anyone needed it,
so it is not a requirement.


Steve