From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <9front-bounces@9front.inri.net>
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED,
	HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI autolearn=ham
	autolearn_force=no version=3.4.4
Received: from 9front.inri.net (9front.inri.net [168.235.81.73])
	by inbox.vuxu.org (Postfix) with ESMTP id 040CC201CA
	for <ml@inbox.vuxu.org>; Wed,  8 May 2024 16:19:52 +0200 (CEST)
Received: from mail.posixcafe.org ([45.76.19.58]) by 9front; Wed May  8 10:17:48 -0400 2024
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posixcafe.org;
	s=20200506; t=1715177857;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=Dgk815F+fUIRyIWvhtkfcBiZ3JLM/4RPBELS8YuuQqE=;
	b=YeHCk9gINiNQE6az3s/qTe9VDXiucZWOgzUTLhbeOS6bhB45+n8gUbcI4fUx3Qdy3d7zDQ
	0u1OiQeSQVXTopYgNkgFK9LmMOaEJR6/Mg+rCeo4s5Yy/VDgMSbQk3ZNhBHXjRtGrXxeIk
	2TGV5JoAsRg1aX9FUtPN9O04g/J8RMU=
Received: from [192.168.168.200] (<unknown> [207.45.82.38])
	by mail.posixcafe.org (OpenSMTPD) with ESMTPSA id 350da597 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO)
	for <9front@9front.org>;
	Wed, 8 May 2024 09:17:37 -0500 (CDT)
Message-ID: <f4f76664-772c-4d08-96e9-9bd29e97dccb@posixcafe.org>
Date: Wed, 8 May 2024 09:17:44 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: 9front@9front.org
References: <EF0CB12C244C188AEAB843273BB12DE7@gaff.inri.net>
 <e377d7a0-2adf-404a-ad33-4119637d4150@fjrhome.net>
Content-Language: en-US
From: Jacob Moody <moody@posixcafe.org>
In-Reply-To: <e377d7a0-2adf-404a-ad33-4119637d4150@fjrhome.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: proven pipelining method-aware scripting-based generator 
Subject: Re: [9front] Enabling a service
Reply-To: 9front@9front.org
Precedence: bulk

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.