User Tools

Site Tools


inbox:snapshot

Differences

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

Link to this comparison view

Next revision
Previous revision
inbox:snapshot [2014/08/24 20:40]
gui created from John Crispin's mail to Battlemesh mailing list
inbox:snapshot [2016/02/04 19:28] (current)
tmomas typo correction
Line 1: Line 1:
-normally we have squash + jffs2 overlay. what we do instead is this ...+====== Filesystem snapshot feature: /​sbin/​snapshot ======
  
-we don't use rootfs_data for jffs2 anymore but instead use it to store +This feature was listed in [[https://​lists.openwrt.org/​pipermail/​openwrt-devel/​2014-July/​026713.html|Barrier Breaker announcedocumentation requested]]The following information comes from [[http://ml.ninux.org/​pipermail/​battlemesh/​2014-March/​002894.html|this post on the Battlemesh mailing list]] by the programmer who implemented it.
-a chain of erasesize aligned blockseach block has a header and a tar +
-file inside itheader has sizehash, and typethere 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 +===== Use cases =====
-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 +//There are many use cases where this makes sense, however it should not be seen as the new replacement for jffs2.// \\ 
-the default configonce your system has booted ​and jffs2 init is +This stuff is aimed at deployments,​ where many units run the same firmware and should all get the same updates at the same timeWe aim to store config ​and small fixes in the block chain. After allit is a tmpfs we run on.
-donesimply call +
  
-  # snapshot ​convert+The cool thing is, that you can simply rollback to an existing ​snapshot ​if anything fails. A trigger for a rollback could be "​can'​t 
 +connect to mesh anymore"​ etc.
  
-this will turn your +===== Implementation details =====
-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 +Normally we have squash + jffs2 overlay. What we do instead is this... 
-changes in /​etc/​config/​ get lost on boot. so there is a mechanism to + 
-write the content of /overlay into the volatile block.+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. 
 + 
 +===== Usage ===== 
 + 
 +You can test this <​del>​in trunk images</​del>​ right now. 
 +The tool is deployed in the default config since Barrier Breaker. 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   # snapshot config
  
-if at any point am happy with my current config, ​can also snapshot +If at any point am happy with my current config, ​can also snapshot the system. ​This will essentially convert an existing volatile entry to a snapshot entry.
-the system. ​this will essentially convert an existing volatile entry +
-to a snapshot entry.+
  
   # snapshot push   # snapshot push
  
-when overwriting blocks (i.e. writing a new volatile +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.
-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 +There is also 
  
   # snapshot upgrade   # snapshot upgrade
  
-this will try to pull opkg updates from the server, for example a  +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.
-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.1408905613.txt.bz2 · Last modified: 2016/02/04 12:51 (external edit)