Re: [9front] Enabling a service

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

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.


On 5/8/24 00:09, sl@stanleylieber.com wrote:
>> Contrary to many people's experience, I actually find
>> that for the kind of latency I get over coffee shop wifi
>> to my home, remote rio sessions behave fairly well (though
>> displaying static images is quite painful).
> but this doesn't actually sound contrary.
>
> text is generally fine, even in drawterm-over-the-internet.  it's when
> you try to work with anything other than text that life gets hectic.
> i never had a lot of complaints until plan 9 became more than a text
> editor for me and i started trying to live in it full-time.
>
> people nowadays are doing a lot more with their plan 9 than they were
> even when we started 9front.  but most of that stuff is either too
> painful to be practical or flat out impossible unless your constituent
> distributed parts live close together on a fast network.
>
> the end result is that many of the very cool features we come to plan
> 9 for in the first place are pretty much useless most of the time.
> and this drives travelers to just running stand alone systems.
>
> this inherent tension between "plan 9 is a distributed environment"
> and "nobody expected us to be quite *that* distributed" remains
> unresolved, and largely unaddressed.  it's not really a fault of the
> original concept, but it does expose weaknesses (or, perhaps more
> accurately, period appropriate shortsightedness nobody could blame
> them for) in the specific implementations of various components.
>
> i like the suggestions made so far about automatic caching schemes.  i
> have played around with cfs partitions, but that mechanism at least
> never seems to deliver the promised results.
>
> sl
>