From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <475efbaa159da90890aaa976272045ee@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Sun, 18 Nov 2007 00:08:10 -0500
To: 9fans@cse.psu.edu
Subject: Re: [9fans] /n/sources/contrib/
In-Reply-To: <0cbda7d7e6f1a9e438a3b3cfc85c42ca@proxima.alt.za>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: ff564516-ead2-11e9-9d60-3106f5b1d025

> That makes a lot of sense.  How practical is it?  At minimum, there
> would have to be a dedicated Venti to isolate "contrib" from other
> sections, plus the arenas would be large: not everyone has broadband
> access.

only the differences in the arenas would need to be copied.  by definition,
the differences in the arenas are not bigger than the differences in the files.
bonus: you don't have to calculate the differences in the files.

this is something i am doing with ken's fs.  i think the outline is the same
for venti.  though given superblocks n, n+1 on the fs, one knows which
data to copy as superblocks are labeled by w address (block number).
the starting lba is waddr(n)*(RBUFSIZE/512) and you need to copy
(waddr(n+1)-waddr(n))/(RBUFSIZE/512) disk blocks.

not quite sure how that translates to venti.

- erik