Re: [9front] Enabling a service

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

How did it work for Venti when there were multiple users?

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.

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.


On 5/8/24 10:17, Jacob Moody wrote:
> On 5/8/24 03:39, Frank D. Engel, Jr. wrote:
>> Some of this latency problem might be helped, at least for reading, by
>> keeping a local cache of the data in the remote file system.
>>
>> Fossil/venti may actually suggest a way of doing this.
>>
>> Think of having blocks of data cached locally in a modified venti
>> structure based on (usage_time, venti-hash, data_block), such that
>> instead of making the data permanent, data with a sufficiently old
>> usage_time may simply be overwritten when more space is needed, and the
>> usage_time is updated when the data is used again.
>>
>> The fossil remote filesystem would be fossil-like, holding the hash for
>> the data blocks, such that data written to it is write-through from the
>> remote (laptop) end of things, being written to the cache using the
>> calculated hash (yes, that rhymes) as well as sent to the disk server
>> across the (latent) network; when data needs to be retrieved, it obtains
>> the hash from the remote side, then checks the local cache to see if a
>> copy is available.  If so, it can simply use the local copy it has from
>> the cache, otherwise it requests it from the other end.
> This would likely work fine for a single user but the merging of data
> in use by a handful of people becomes quite the challenge.
>
>
>