User Tools

Site Tools


inbox:snapshot

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

inbox:snapshot [2014/08/24 20:40] (current)
gui created from John Crispin's mail to Battlemesh mailing list
Line 1: Line 1:
 +normally we have squash + jffs2 overlay. what we do instead is this ...
 +
 +we don't use rootfs_data for jffs2 anymore but instead use it to store
 +a chain of erasesize aligned blocks. each block has a header and a tar
 +file inside it. header has size, hash, and type. there are snapshot
 +and volatile blocks. the volatile entry can only exist once and as the
 +last sentinel of the block chain.
 +
 +upon boot, the unit mounts squash, does an overlayfs mount, but uses a
 +tmpfs instead of the usual jffs2 (which doesn'​t exist anymore).
 +we unpack the tar files in the order found inside the chain. ​
 +once all snapshot blocks are unpacked, we do another stacked overlayfs
 +mount with a tmpfs and unpack our volatile block into it. we now have
 +a stacked overlay root with /snapshot holding the delta of the first
 +and /overlay holding the delta of the second mount.
 +
 +you can test this in trunk images right now. the tool is deployed in
 +the default config. once your system has booted and jffs2 init is
 +done, simply call 
 +
 +  # snapshot convert
 +
 +this will turn your
 +current jffs2 overlay delta into a block chain with a single volatile
 +block.
 +
 +the system is now essentially similar to an initramfs image, where the
 +changes in /​etc/​config/​ get lost on boot. so there is a mechanism to
 +write the content of /overlay into the volatile block.
 +
 +  # snapshot config
 +
 +if at any point i am happy with my current config, i can also snapshot
 +the system. this will essentially convert an existing volatile entry
 +to a snapshot entry.
 +
 +  # snapshot push
 +
 +when overwriting blocks (i.e. writing a new volatile
 +over an existing one or while converting a volatile to a snapshot) we
 +use the last few sectors of the flash as a back buffer. this way we
 +have a valid copy of the "data to be deleted"​ while we are overwriting
 +it. this allows us to always be able to fallback to the last known
 +working version.
 +
 +there is also 
 +
 +  # snapshot upgrade
 +
 +this will try to pull opkg updates from the server, for example a 
 +security fix, and if it does find one or more it will automagically
 +install the updates and then save this as a snapshot entry in the chain.
 +
 +there are many use cases where this make sense, however it should not
 +be seen as the new replacement for jffs2. this stuff is aimed at
 +deployments,​ where many units run the same firmware and should all get
 +the same updates at the same time. we aim to store config and small
 +fixes in the block chain. after all, it is a tmpfs we run on.
 +
 +the cool thing is, that you can simply rollback to an existing
 +snapshot if anything fails. a trigger for a rollback could be "cant
 +connect to mesh anymore"​ etc
  
inbox/snapshot.txt · Last modified: 2014/08/24 20:40 by gui