Re: [9front] Enabling a service

["Frank D. Engel, Jr." <fde101@fjrhome.net>]

When you perform a write, you send that write to the file server on the 
remote system and it updates the block, generating the appropriate 
hash.  If another client sends a write with a collision, the file server 
handles it the same way it already would - the two are ultimately 
processed in some order or another.

Each client system may have updated a locally cached copy of the block 
with the same written data, but if the data did not match what was 
generated on the file server because it was updated in the meantime, 
then the hash on the client system will not match what the remote server 
came up with.

Consequently, when it later tries to read that block again, the file 
server sends it the hash that it has, which does not exist in the local 
cache, so the client is forced to request the correct block from the 
file server instead of using the locally cached copy.

Similarly, the other client performed its write and has yet another 
different hash, since the server has the data from both clients.  When 
that client tries to perform another read, its hash won't match either, 
forcing it too to obtain the correct copy of the data from the file server.

Had only one of them been manipulating the data, then that one would 
have the correct copy with a matching hash, so it would be able to use 
its local copy.


On 5/8/24 12:10, Jacob Moody wrote:
> On 5/8/24 10:49, Frank D. Engel, Jr. wrote:
>> How did it work for Venti when there were multiple users?
> My understanding of venti is somewhat limited to take my explanation with a grain of salt.
> If you have divergent fossils using the same venti you will get divergent root scores, they
> become two paths that have to be merged manually.
>
>> You still have a single source of truth on the file server as all of the
>> data would still be written there with this approach and it would still
>> manage the directory structure, so any data that would come from other
>> users would ultimately just be pulled from the file server and loaded
>> into their cache separately.
> I got your proposal the wrong way around, you are talking about a local
> venti and a remote fossil. At the point you decide that you want a single
> remote source of truth(filesystem) that everyone must reconcile with you are still going
> to have issues with merging. Venti works as a backing for multiple disjoint fossils
> because it has no single source of truth for the filesystem, it just stores blocks.
>
> No matter how you cut you are going to have to deal with multiple people merging
> their cache in to the single root of truth with potentially latent updates.
> Either you have to serialize all mutations at the source of truth (and at that point
> you are latent bound) or you have to be clever about merging. A lot of ink has been
> spilled about this problem in the scope of web programming (CRDs iirc), perhaps
> that may serve as some inspiration.
>
>> One challenge might seem to be simultaneous writes to different parts of
>> the same block, but in this case the locally calculated hash for the
>> block that was written to cache would (hopefully) not match the one
>> calculated by the file server which would reflect both updates, so when
>> the read would occur the file server would send a hash that would not be
>> in the local cache and the read would be sent across to the file server
>> for the updated block, with the incorrect local block eventually being
>> aged out of the cache as it started to fill up.
>>
>>
> Reading this and rereading your previous email I still do not fully understand
> how you plan to deal with collisions. If you have a local cache that you write
> to first and then you slowly drain that to the remote system you are still
> going to have merge issues. The fileserver is going to say at some point "No
> this is based on stale information" and you'll have to figure out out to retroactively
> reconcile this error with a system that has already forgotten this request.
>
>