Closed sholtrop closed 1 year ago
observations while thinking about implementing this:
a
, change it, remove it, and create a new file a
we should be able to determine that the last a
has nothing to do with the first a
, every step has to be a revision. Do we want this file-based or global? Do we want revisions at all, or can we determine this by the serial number of the raft request?Create
event is maybe not the best course of action, replication_factor should be good, and then we can have different events for "storage events". After replaying the raft log you get the keepers per file, of course. But log-wise seperating these seems logical. In case of node failure, we have to relocate the files, which would lead to a nice separate relocation event. The create event can have the destination nodes inscribed to them for initial storage nodes, yes, but I don't see the reason why this is useful.u64
.Every operation on the FR is guaranteed by Raft to be replicated across all nodes. If you do these steps, they will be seen and performed by every node in the same order. So their FRs will be the same. Given this, why would we need to keep any other information regarding files?
Agreed, let's split Create and Store events
Sounds good
Blockers:
query!
macro to deduce types, currently returns ()
for querying a single file from the the files
table.@sholtrop done?
I'll mark this as done for now and do the rest of the NodeToNodeOperation
as separate items
Overview of all the files in the filesystem, consistently replicated through Raft on every node. It contains, per file:
Implement in Sqlite.