Currently, graft local logs are fragmented due to concurrent writers. But a recent bug discovered in the snapshot code means my solution for concurrent writes was fundamentally wrong anyway.
So I need a new solution for local logs + concurrent write/push/pull ops.
Raw brain dump on the current state. Probably will only make sense to me.
volume foo
read:
local { (last sync point).next() ..= latest local lsn }
remote { LSN::FIRST ..= latest remote lsn }
after push:
read:
remote { LSN::FIRST ..= latest remote lsn }
write
local { (last sync point).next() ..= latest local lsn }
remote { LSN::FIRST ..= latest remote lsn }
local log on client A:
1..=5 -> pushed to remote 1
.. pulled lsn 5 from remote due to concurrent writes
equivalent to git rebase remote:5, but dropping any commits that we
integrated: 1..=5, now local is just a "pointer" to a empty state
on top of remote:5
6..=8 -> based on remote lsn 5 pushed to remote 6
if you try to read only from the local log:
1..=8
-> this is corrupt
local 6..=8
remote 2..=5
local 1..=5 == remote 1
local 6..=8
remote 1..=5
-- new branch model
read: lookup local branch
[local { LSN::FIRST ..= latest local lsn }]
remote { LSN::FIRST ..= latest remote lsn }
write: lookup local branch
-> create new local branch
-> write to the local branch
push:
-> get local branch
write:
-> get local branch
push:
-> push it to the remote
write:
-> commit to local branch
pull:
-> push it to the remote
after push:
read:
remote { LSN::FIRST ..= latest remote lsn }
write
local { (last sync point).next() ..= latest local lsn }
remote { LSN::FIRST ..= latest remote lsn }
Currently, graft local logs are fragmented due to concurrent writers. But a recent bug discovered in the snapshot code means my solution for concurrent writes was fundamentally wrong anyway.
So I need a new solution for local logs + concurrent write/push/pull ops.
Raw brain dump on the current state. Probably will only make sense to me.