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 DE5A4268D9 for ; Wed, 8 May 2024 19:28:42 +0200 (CEST) Received: from mail.posixcafe.org ([45.76.19.58]) by 9front; Wed May 8 13:27:11 -0400 2024 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posixcafe.org; s=20200506; t=1715189220; 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=aF3PVtXmZPQ9exKlwGcguv/2LWnepcItZeeZgmNpfYo=; b=VsRPMnG1OyCDFFRy+NAQdZTnC+tBE8honpp/Eis7wXej/0PhXNIV1Zy3YmvF+w7Q+KyZDz iehNx0QGlYaVY8ff0fTDJ4Vc4EE5d0G8xFoUiavMWn8OYKy9+fiiRSV5yfo3iO5Yn529NO M0+Ey1Yd+envbG830+HzsaaReJaAwUk= Received: from [192.168.168.200] ( [207.45.82.38]) by mail.posixcafe.org (OpenSMTPD) with ESMTPSA id c72d720b (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for <9front@9front.org>; Wed, 8 May 2024 12:27:00 -0500 (CDT) Message-ID: Date: Wed, 8 May 2024 12:27:07 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: 9front@9front.org References: <328dc131-044d-408d-a040-512a44ae6e7b@fjrhome.net> <9df183e7-7a94-4d58-9a68-2dbc0e73018f@posixcafe.org> <959215bb-a8d0-40b9-bbd5-89c21a90c9ac@fjrhome.net> Content-Language: en-US From: Jacob Moody In-Reply-To: <959215bb-a8d0-40b9-bbd5-89c21a90c9ac@fjrhome.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: optimized extended JSON over JSON rich-client factory standard Subject: Re: [9front] Enabling a service Reply-To: 9front@9front.org Precedence: bulk On 5/8/24 11:33, Frank D. Engel, Jr. wrote: > 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. > Thank you I see the full picture now, using the hashes for checking against the server. It sounds like it would work as well as any central filesystem does for multiple users.