Changes

Jump to: navigation, search
no edit summary
==Gateway and server configurations==
Regarding the gateway's software configuration, it resembles the one described [[MISC-TN-004:_Running_Debian_(armbian)_on_SBCSPG|here]]. In this case, however, a symmetric update scheme was adopted (see also . As such, the rsulting partitioning is a little bit different as shown in the following image. For the sake of simplicity, the implemented update mechanism aims to update the Linux kernel image along with the associated device tree blob and the root file system as a whole (monolithic update).  [[File:MISC-TN-012-symmetric-update.png|center|thumb|Symmetric update scheme]]   Symmetric updates rely on two mirror copies of the system, each comprising kernel and root filesystem in this specific case. They are labeled as A and B in the figure. If A is running, an incoming update overwrites B. Then the system reboots, switching to B. The two copies swap their roles after every successful update. Clearly, the system continues to run the same copy whenever a failure occurs: in any case, the device’s integrity is ensured. The most pleasing benefit of symmetricupdates is that they allow the device to continue executing its usual tasks since the inactive copy is updated separately in the background. Furthermore, only the minimal downtime of a single reboot is required. There are two downsides as well: the storage space needed for a redundant copy is doubled compared to the asymmetric scheme and the large size of the update packages can put a strain on the network infrastructure. The latter can be mitigated by sending only the filesystem blocks that have changed with respect to the previous version (binary delta update).
4,650
edits

Navigation menu