oh, another interesting details that I have only recently got says that it must be a "disk-btree" algorithm!
It means you have to access 1Kbyte by some provided API's functions (e.g. disk_read(..), disk_write(..), ..) and you will get 1Kbyte of structure where your BTREE/B+TREE's data must reside.
(btree != b+tree, but I have one degree of freedom, I can change the request into b+tree if it's better)
seeks are assumed << 5mSec, but it down't matter, since now we know that it's a disk-btree! So, we have to consider: pointers to memory, vs disk access, and this changes a bit of things in my previous design draft (at least the data structure )
The good news is that disk is not an electro-mechanical device, and it's not pATA/sATA, it's a custom solid state device with it's custom protocol, and probably it's made with FeRAM chips, but chips may be flash-chips. Who knows ?
From a low-level requirement I read that there is also a bit super capacitor able to keep the device powered for enough time to flush data from RAM into the chips. There is a specific interrupt for that, and algorithms must keep flying-datas written onto chips as fast as possible.
Thanks god there is no (not yet?) request for "journaling". Not related to the btree.
But there is a request for a chunk of data that needs to be written into chips collecting information about failures during the missions, warm/cold start, and tons of other information. That is the easiest part, since it doesn't imply btree. It's just a circular buffer!
So, the module I have to prepare is composed by two sub-modules: btree, and circular buffer.
I will reserve the first blocks to the circular buffer, and the rest to the database.