Hello all, I have seen the Video (0). At the end there is the question how to make drivers for block devices restart able. The only limiting factor for this is state, according to the video. To store state in restart able processes raft(1) was invented. Especially this implementation has enough modularity to be adaptable to store its data on raw block devices. Another key part of the solution is transactional application of log segments. For this 3 fixed root blocks are needed. Every time you need to apply some segment to a root block you overwrite first a pointer (block number) in the root block with the address of the log segment you want to apply. >From this time on after reading something from that root block and anything pointed to from it you apply that segment. Ok, you will never implement it that way. You load a raft process with the data on restart and continue to run from this loaded data as if you had written that pointer this instant. Now you prepare the next root block by doing a cow operation on the data reachable from the old root block. At last you set the version field in the new root block and set the segment pointer to an empty value. Now you need to look at the version fields of all 3 root blocks on storage. There are 6 permutations of them but only one of them will fulfill the equation H(a,b)=c. (with H as a cryptographic hash) This permutation assigns to every one of the root blocks a letter. The letter a is for overwrite, the letter b is for backup and the letter c is for the current root block. The new version field is calculated H(b,c) and the new root is written to a. I think that allows fully transactional restart able block devices. The storage of the root blocks can but doesn't have to be on the same device of the Filesystem the root blocks are managing. (1)https://github.com/canonical/raft (0)https://video.fosdem.org/2021/D.microkernel/microkernel_pluggable_device_dri...
Hello Uwe,
On 22.04.21 21:50, Uwe wrote:
I have seen the Video (0). At the end there is the question how to make drivers for block devices restart able. The only limiting factor for this is state, according to the video. To store state in restart able processes raft(1) was invented. Especially this implementation has enough modularity to be adaptable to store its data on raw block devices.
thanks for commenting on my talk and for sharing your perspective.
The stance I expressed is primarily an economic one. For driver classes covered by the talk (network, graphics, input), the architectural change towards the pluggable device drivers actually reduced the interface complexity, which is beautiful. The main concern were drivers in the order of 100 thousand lines code (thinking of the wifi or intel graphics drivers), which are no longer critical for the liveliness of the system. So when looking at the effort, complexity implications, and benefit, this change is a clear win.
For block drivers, the equation looks different.
First, each of our block drivers (NVMe, AHCI, USB block) comprises about 1500 lines of code. With this rather low complexity, we can attain robustness by the means of code-quality measures. When equaling risk with source-code complexity, the pressure to make block drivers restartable is two orders of magnitudes weaker compared to the drivers mentioned above.
Second, the restartability mechanism would introduce new risks. We are faced with the problem of replicating large states. Even though solutions exist, they introduce new complexity instead of taking away complexity. Intuitively, I think that a solution would likely exceed the 1500 lines of code of the block driver. So the net gain from a risk-assessment perspective is dubious.
That being said, please don't take my words as discouragement. If you are interested to explore this direction, I'd be delighted to learn about your findings.
Cheers Norman
Gesendet: Dienstag, 27. April 2021 um 16:03 Uhr Von: "Norman Feske" norman.feske@genode-labs.com An: users@lists.genode.org Betreff: Re: Restart able block devices
Hello Uwe,
On 22.04.21 21:50, Uwe wrote:
I have seen the Video (0). At the end there is the question how to make drivers for block devices restart able. The only limiting factor for this is state, according to the video. To store state in restart able processes raft(1) was invented. Especially this implementation has enough modularity to be adaptable to store its data on raw block devices.
thanks for commenting on my talk and for sharing your perspective.
The stance I expressed is primarily an economic one. For driver classes covered by the talk (network, graphics, input), the architectural change towards the pluggable device drivers actually reduced the interface complexity, which is beautiful. The main concern were drivers in the order of 100 thousand lines code (thinking of the wifi or intel graphics drivers), which are no longer critical for the liveliness of the system. So when looking at the effort, complexity implications, and benefit, this change is a clear win.
For block drivers, the equation looks different.
First, each of our block drivers (NVMe, AHCI, USB block) comprises about 1500 lines of code. With this rather low complexity, we can attain robustness by the means of code-quality measures. When equaling risk with source-code complexity, the pressure to make block drivers restartable is two orders of magnitudes weaker compared to the drivers mentioned above.
The raft implementations have around 2000 SLOC. Although I don't believe in SLOC as Measurement of complexity I would think it comparable. But if the implementation can be shared like ROMFile it would be unimportant because the complexity would be distributed.
Second, the restartability mechanism would introduce new risks. We are faced with the problem of replicating large states. Even though solutions exist, they introduce new complexity instead of taking away complexity. Intuitively, I think that a solution would likely exceed the 1500 lines of code of the block driver. So the net gain from a risk-assessment perspective is dubious.
The raft implementation would allow additional uses. Like the reorganization of the graphics allows screenshots for free the raft implementation will allow simply powering off the computer. If it is used to allow the seamless update of applications It would allow at the same time continuing the work after powering off and reboot. With additional connectivity to a matching cloud service it's even possible to surprisingly destroying a computer and reboot a brand new computer, connecting to the server and continue the work where the old computer was destroyed. But In contrast to remote desktop the work is done locally and the service only stores data. The difference is important if the connection is flaky.
That being said, please don't take my words as discouragement. If you are interested to explore this direction, I'd be delighted to learn about your findings.
It is pretty discouraging because there is an interdependence between raft and block devices. The other features won't probably work without raft in the block device.
Cheers Norman
-- Dr.-Ing. Norman Feske Genode Labs
https://www.genode-labs.com · https://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
-
Norman Feske -
Uwe