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.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 6110E21570 for ; Wed, 8 May 2024 23:19:32 +0200 (CEST) Received: from heron.birch.relay.mailchannels.net ([23.83.209.82]) by 9front; Wed May 8 17:17:57 -0400 2024 X-Sender-Id: dreamhost|x-authsender|lists@ecloud.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 94F5F141307 for <9front@9front.org>; Wed, 8 May 2024 21:17:49 +0000 (UTC) Received: from pdx1-sub0-mail-a291.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 36A01141DB7 for <9front@9front.org>; Wed, 8 May 2024 21:17:49 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1715203069; a=rsa-sha256; cv=none; b=NoxOzs6G7WiyMio75BR+j35IOA7sIuwJR6PJHxc5x0FvNL5dbtcTisALTHZ8pw8W5pcRbe yHg/VhcBP40i9BzPOJefSGfDrGFFMsbdk5X9526adMILHmzLdDSgqgSKB5dcxtx7DQvdJJ duj3zCfP+tO9zQPcDb8sVoeY5MxC8Lco2HfP1W13dSPR0QBCul5pZ3xDHEpkCT0lnb8ixO k9thpsUop6og8Vq/6IK/C7HEvHcziU8Ke8VqnHlG5ZUPpvSDWC6xZPod6NxvdrxHA3+01+ b8+GY5K4yKr3rR+tsyGC/pmYLrsHvo9IYYC0u858JzoTr4u+l5q9zCBjn4VOUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1715203069; 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:dkim-signature; bh=gHvn+ECo9JV6wks/nTmXYVxWu/C6SNEE1PkNj6M4C/g=; b=KphW+OGBrgJ3vFNDWQHUzHc4kBxvj8p+sxaFS6PBJeW3+5Mgi0YkCNp9LnCiYK45tXepNr bVopH6zbdH2RMiVss4DGr1jdbrLXg6O4EYmfVsqrFla4ZM9qERcEi4QHxHC4Ss/WIkRwQE kLS4QKNH8y/5NFkaIOD4yH1sEvxDPRitoWyKfHFV+Y832Xa5QcjLaVB/eIDmg2cCe34GXR EwlDWVFFPkbg2GFZgjsj2Ek6SSYx8wFnh/qbwiusrZhs/f7enao98xtI3t36USrG2b9DAB PogQQ84eiAfT8knXLAB333K82PqOeYs6I2irDtDPfxtZHn82GCd82OpVTOulQw== ARC-Authentication-Results: i=1; rspamd-68bbddc7f5-cp97x; auth=pass smtp.auth=dreamhost smtp.mailfrom=lists@ecloud.org X-Sender-Id: dreamhost|x-authsender|lists@ecloud.org X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|lists@ecloud.org X-MailChannels-Auth-Id: dreamhost X-Broad-Broad: 12f56d6a4a5cb20a_1715203069458_1057808315 X-MC-Loop-Signature: 1715203069457:2853629363 X-MC-Ingress-Time: 1715203069457 Received: from pdx1-sub0-mail-a291.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.116.218.200 (trex/6.9.2); Wed, 08 May 2024 21:17:49 +0000 Received: from smtpclient.apple (154.sub-75-233-59.myvzw.com [75.233.59.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: lists@ecloud.org) by pdx1-sub0-mail-a291.dreamhost.com (Postfix) with ESMTPSA id 4VZSfN70pwzcy for <9front@9front.org>; Wed, 8 May 2024 14:17:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ecloud.org; s=dreamhost; t=1715203069; bh=gHvn+ECo9JV6wks/nTmXYVxWu/C6SNEE1PkNj6M4C/g=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date:To; b=KjqtcwTPkDWN//LqWsbOSB0l3L3YYFHz8Z7DM3qrAO7b8PU17XM1Q/X+chBL8e+RC X2Bc9LSq1p1+5gFXF+LB2gmVJDnpybpTv+1Xf1WqH3xfpRdOeyJWSs6izbzeV0rAKH tbMrjeHFMWQtbFxEz51mTJ7XU5/dICTfpfOOcCawiTDkCQrUYoj5FLBq5ju4YlMZwj WB9VpJF9oIPELj0RjuxCnC0WEhQZ4/50Bv+JUusgiAI1pRvoNQ4y0YScmToVtNRixm ZYmF+hUPXNZJ/rYZwQdXuRPN4h+bVjj2EysuifL1gb9Fd3MHnktJArtMxigxKvdeFE uslA8fU0HFz6g== From: Shawn Rutledge Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Date: Wed, 8 May 2024 14:17:34 -0700 References: <102b2835-4207-4f8c-9f29-9da8b459dc2e@posixcafe.org> <5CF629DBC32C6D8D674AE2E07A2F8289@gaff.inri.net> To: 9front@9front.org In-Reply-To: Message-Id: <863BD749-CEEC-401E-9762-367B1ABA1367@ecloud.org> X-Mailer: Apple Mail (2.3774.500.171.1.1) List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: map/reduce session interface Subject: Disconnection-tolerant / distributed filesystems (was Re: [9front] Enabling a service) Reply-To: 9front@9front.org Precedence: bulk > On May 8, 2024, at 9:37=E2=80=AFAM, Brian Stuart = wrote: >=20 >> Anyway, shout-out to inferno-bls's lapfs. >=20 > I had played with a few different variants on the idea, though all > quite a while back. To give an idea of just how far back, I presented > it at the 4th IWP9 15 years ago: >=20 > https://www.cs.drexel.edu/~bls96/lapfs.pdf >=20 > Maybe it's about time to pull it out of mothballs and do fresh 9native > and *nix versions. Cool, I read it just now. For limbo, not having 64-bit support seems to be an obstacle. Am I = missing something? I didn=E2=80=99t succeed in getting 9ferno working = yet, but isn=E2=80=99t it working in theory? I=E2=80=99ve been following (and trying to use) ipfs for a while. It = seems that using it as a mounted filesystem was not a priority (those = guys seem to care about web applications first, and calling it a = filesystem was a stretch at first; perhaps it still is, but I need to = test the latest version). But the core idea of using a storage = block=E2=80=99s hash as its ID and building Merkle trees out of those = blocks seems like a good way to build a filesystem to me. A file is = then identified by its cumulative hash (i.e. probably the hash of the = block that is the head of the metadata pointing to the data blocks). = Then maybe you no longer care about comparing paths and timestamps: if = both the laptop and the file server have hash tables to keep track of = which files and blocks they=E2=80=99re storing, checking whether a = particular file is cached should be very fast and not depend on walking = so much. When planning for a laptop to be away from the file server for a while = (and not assuming that network access is always available) I=E2=80=99d = want to pre-sync some directories. On filesystems that have extended = attributes, I was thinking it would be nice to just set an attribute = ahead of time (sharing peers or channel ID or something) and be able to = verify the sync state later, before disconnecting from the file server. = But 9p doesn=E2=80=99t support those, so any automated sync arrangement = has to be a separately-configured process. Currently I use syncthing, = but I suppose it does more work than it would need to if the filesystem = were designed to make syncing more efficient. Fanotify is a big win for = syncing with less walking on Linux though. (I used it myself in a = syncing experiment.) But then I was thinking one downside of the ipfs approach is just the = difficulty of maintaining a Merkle tree, depending on how you like to do = typical file modifications. Blocks could form an intrusive linked list, = using their neighbors=E2=80=99 hashes as pointers: but they=E2=80=99d = better not point directly, because it would de-optimize updates = everywhere but on one end. (Imagine what rrdtool would do to it. If = your philosophy is that storage is growing fast enough, why delete = anything ever - then a simple log is better. But rrdtool is very = efficient if storage is limited and random writes are cheap. It might = even turn out that some blocks in the database file are stable over some = time periods.) So the index of blocks that make up a file probably = should be completely separate. Still, the index itself takes some = blocks; and if the index is a Merkle tree, then every write could = potentially invalidate most of it. (Although a suitable design could = make appending cheap, or some other selective optimization.) The = filesystem should be venti-compatible, so minimizing garbage would be = best. Anyway, even if only the actual data blocks are hashed, you have easy = venti compatibility and at least somewhat easier checking of what is = synced and what is not. Migrating any amount of data between any number = and size of storage devices ought to be easier. Aren=E2=80=99t filesystems like zfs built on hashing too? But zfs = includes the block layer rather than building on top of a generic block = layer. Explicit layering should yield some benefits, I imagine.