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.8 required=5.0 tests=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 2641921BE1 for ; Wed, 8 May 2024 17:53:15 +0200 (CEST) Received: from dpmailmta02.doteasy.com ([65.61.219.33]) by 9front; Wed May 8 11:50:03 -0400 2024 X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=192.168.101.82; Received: from dpmailrp02.doteasy.com (unverified [192.168.101.82]) by dpmailmta02.doteasy.com (DEO) with ESMTP id 124853733-1393315 for <9front@9front.org>; Wed, 08 May 2024 08:49:59 -0700 Received: from dpmail01.doteasy.com (dpmail01.doteasy.com [192.168.101.1]) by dpmailrp02.doteasy.com (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id 448Fnw35032449 for <9front@9front.org>; Wed, 8 May 2024 08:49:59 -0700 X-SmarterMail-Authenticated-As: fde101@fjrhome.net Received: from [192.168.1.95] (pool-173-67-134-57.hrbgpa.fios.verizon.net [173.67.134.57]) by dpmail01.doteasy.com with SMTP (version=Tls12 cipher=Aes256 bits=256); Wed, 8 May 2024 08:49:39 -0700 Message-ID: <328dc131-044d-408d-a040-512a44ae6e7b@fjrhome.net> Date: Wed, 8 May 2024 11:49:32 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: 9front@9front.org References: Content-Language: en-US From: "Frank D. Engel, Jr." In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Exim-Id: 328dc131-044d-408d-a040-512a44ae6e7b X-Bayes-Prob: 0.5 (Score 0, tokens from: base:default, @@RPTN) X-CanIt-Geo: No geolocation information available for 192.168.101.1 X-CanItPRO-Stream: base:default X-Canit-Stats-ID: 01ckDNW3N - 5778f7c5310f - 20240508 X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.101.82 X-Originating-IP: 192.168.101.82 List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: open-source cache SOAP over ORM firewall table package polling optimizer Subject: Re: [9front] Enabling a service Reply-To: 9front@9front.org Precedence: bulk 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. > > >