On Sunday, 27 October 2024, at 10:57 AM, Ole-Hjalmar Kristensen wrote:
> I
have tried it out by feeding it with the output from printarenas, and
it seems to work reasonably well. Does anyone have any good ideas about
how to incrementally extract the set of scores that has been added to a
venti
I just stumbled across this thread, so I will repost something I wrote in
2017 about mirroring of venti. I had the need to create the union of two
venti servers, so I wrote a client that copies individual venti blocks,
given the scores. This you can do without worrying about what is on the
target v
That's familiar enough that TBH I probably saw your message and forgot
to respond. I was going through Some Shit at the time.
I'm cleaning up my inbox today; I'll respond if I see it and reach out
if I don't :)
- Noam Preil
--
9fans: 9fans
Permalink:
http
On Sunday, 4 August 2024, at 2:57 PM, noam wrote:
> i'm unsure which thread you're talking about; can you link me to
more info on mventi? I've been working on a better venti implementation
as well [1], and it'd be nice to have another reference :)
The other thread is "yet another try to fixup venti
Quoth wb.kl...@gmail.com:
> Noam is right in most of his text.
Well of course, I'm me, what do you expect? :D
> But I have to add that the following sentence should be taken with some grain
> of salt.
Everything should be taken with at least one grain of salt, preferably
more; salt is essential
Quoth kalona.ayeli...@fastmail.us:
> While I've received some help, it wasn't clear. I haven't asked for further
> clarification because I know I would receive more banter for asking simple
> follow-up questions.
If you ask questions, I'll happily answer them.
Banter you've received was specif
Quoth kalona.ayeli...@fastmail.us:
> I see this as a documentation problem. If people can't find information
> easily, they ask. Without credible documentation, the cycle never ends. We
> have endless discussions on 9fans on how to do things. Improving
> documentation is a step forward. Is aski
Thanks Noam for that summery; it's of great help.
-marco
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tca0eb0fbb2404e31-Mc78af745108ea6a349ba9966
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Code serves as a better single source of truth than 9fans. If you rely on 9fans
for accuracy, it's understandable to be upset when the quality of posts is
lacking. Accurate documentation is crucial when 9fans' quality declines.
If everyone shirks responsibility for documentation, the problem wil
03.08.2024 21:06:54 kalona.ayeli...@fastmail.us:
> Naom, 9fans isn't a single source of truth, but rather is a place for holding
> discussions.
Code doesn't lie. So code is the source of truth. Anything you say about how
things work which doesn't match reality, is therefore just wrong or a lie.
Noam is right in most of his text.
But I have to add that the following sentence should be taken with some grain
of salt.
> If the index is on a separate drive, though - e.g. index on SSD, data on HDDs
> - mirrorarenas can be used to keep the arenas in sync between multiple (sets
> of) HDDs,
khm, if you need validation as an expert, that's on you.
Naom, 9fans isn't a single source of truth, but rather is a place for holding
discussions.
I see this as a documentation problem. If people can't find information easily,
they ask. Without credible documentation, the cycle never ends. We
Quoth kalona.ayeli...@fastmail.us:
> khm, you can think whatever you like. If true, then all you can do is let it
> be.
>
> My point is accurate information should be easy to find and read
if you care about accurate information, the most helpful thing you can do
is stop using LLMs.
Sincerely, p
Quoth kalona.ayeli...@fastmail.us:
> Would creating standard operating procedures for newcomers be beneficial?
> Having procedures detailing how to administer Venti mirroring on a Plan 9
> system in a wiki seems reasonable. Here is a formatted example of an SOP. I
> am sure something better coul
On Sat, Aug 03, 2024 at 02:27:14PM -0400, kalona.ayeli...@fastmail.us wrote:
> khm, you can think whatever you like. If true, then all you can do is let it
> be.
I don't need your permission to think whatever I like, and there are
tons of other things I can do, like informing you that you're a us
khm, you can think whatever you like. If true, then all you can do is let it be.
My point is accurate information should be easy to find and read, like in a
wiki. Mailing lists are for discussions, not for searching answers. It’s ideal
when discussions lead to action items that improve the overa
On Sat, Aug 03, 2024 at 02:10:43PM -0400, kalona.ayeli...@fastmail.us wrote:
>
> cron '*/5 * * * * fs(3) -m /dev/sdE0/arena /dev/sdE1/arena'
>
When you generate bullshit with an LLM and then post it without reading
it, nobody thinks the LLM is stupid. We think *you* are stupid.
khm
--
Would creating standard operating procedures for newcomers be beneficial?
Having procedures detailing how to administer Venti mirroring on a Plan 9
system in a wiki seems reasonable. Here is a formatted example of an SOP. I am
sure something better could be created.
Standard Operating Procedu
Quoth Marco Feichtinger :
> venti/mirrorarenas is undocumented, and I couldn't find any topic here,
> which goes into more detail.
>
> So I am curious how does it work,
> how does one to set it up, so the arenas get mirrored automatically,
> and why do you use it instead of fs(3) mirror?
fs(3) c
Thank you very much guys, there are some helpful answers,
even though this thread got a little messy. (didn't see that coming)
Charles Forsyth, since you are using venti/mirrorarenas,
if you don't mind, I would like to know what your venti.conf looks like.
-marco
---
Quoth Marco Feichtinger :
> venti/mirrorarenas is undocumented, and I couldn't find any topic here,
> which goes into more detail.
>
> So I am curious how does it work,
> how does one to set it up, so the arenas get mirrored automatically,
> and why do you use it instead of fs(3) mirror?
>
> -ma
11 years ago Russ posted a program called ventino that keeps
its index in RAM. May be you can use it as a starting point?
http://mail.9fans.net/pipermail/9fans/2011-August/020604.html
> On Nov 25, 2020, at 11:13 AM, Steve Simon wrote:
>
> Hi,
>
> I have a pile of sealed venti arenas on an a
Thanks, I found the problem by inspection of src/lib9/_p9dialparse.c.
IPv6 is indeed the default when using an address of tcp!*!17034
/* translate host */
if(strcmp(host, "*") == 0){
ss->ss_family = AF_INET6;
((struct sockaddr_in6*)ss)->sin6_addr = in6addr_any;
}else if((he = gethostbyname(host))
> I can connect to the venti from localhost, but not from any other machine.
> However, if I run nc -l on ports 17034 and 80, I can connect from any
> machine. It is definitely not the packet filter, since the problem persists
> even if I disable the packet filter. Any suggestions about what might
> I see several threads about how people are cloning their Venti
> servers to remote Venti servers as a means of creating a backup.
Personally, I use three different ways of replicating the
content of my Venti file servers.
1. The first method is to use venti/mirrorarenas to replicate
the content
i append my venti arenas to usb memory sticks - only two so far. i don't store
music or videos on plan9 so compressed de-duplicated data doesn't take up much
space.
the only time i had problems was my own fault, over cooling a disk through my
own paranoia.
> On 26 Oct 2016, at 18:43, Steven St
It was exactly this thought that led me to moving my venti store to
running out of plan9port. At home, I have a Linux server that provides
other services in addition to venti with an obnoxious amount of
storage. I also have a CrashPlan client running on this machine. The
result is an always-on back
On Tue, Jan 14, 2014 at 10:48:59PM -0800, Bakul Shah wrote:
> On Jan 13, 2014, at 3:59 PM, Grant Mather wrote:
> > I partitioned the disk using fdisk to create one large OpenBSD
> > partition, and then created two paritions with disklabel, one for arenas
> > and one for isect. I followed the wiki
On Jan 13, 2014, at 3:59 PM, Grant Mather wrote:
> I partitioned the disk using fdisk to create one large OpenBSD
> partition, and then created two paritions with disklabel, one for arenas
> and one for isect. I followed the wiki page for setting up venti, and
> have been able to get it working on
On Tue, Jan 14, 2014 at 03:46:11AM -0800, Michael Hansen wrote:
> Are you using OpenBSD's stock pf ruleset? I don't think it blocks or
> otherwise interferes with any 9Pish ports by default, but it's
> something to check.
> mmh
>
> > Date: Mon, 13 Jan 2014 16:59:13 -0700
> > From: Grant Mather
>
Are you using OpenBSD's stock pf ruleset? I don't think it blocks or
otherwise interferes with any 9Pish ports by default, but it's
something to check.
mmh
> Date: Mon, 13 Jan 2014 16:59:13 -0700
> From: Grant Mather
> (snip)
> Using plan9port-20120508 that is provided with OpenBSD seems to have
OK, thanks a lot for your help!
2012/1/20 David du Colombier <0in...@gmail.com>:
>> Does the presence of the trailer imply that I should add an extra
>> block to the arenas backup?
>> If my last arena is
>>
>> arena='arenas059' [31676186624,32213057536)
>>
>> then I should backup 32213057536+8192
> Does the presence of the trailer imply that I should add an extra
> block to the arenas backup?
> If my last arena is
>
> arena='arenas059' [31676186624,32213057536)
>
> then I should backup 32213057536+8192 bytes instead of 32213057536?
No, the trailer is located at the end of the arena,
just
Does the presence of the trailer imply that I should add an extra
block to the arenas backup?
If my last arena is
arena='arenas059' [31676186624,32213057536)
then I should backup 32213057536+8192 bytes instead of 32213057536?
2012/1/20 David du Colombier <0in...@gmail.com>:
> This is because eac
Thanks a lot, David, for your detailed reply.
I've followed your indications and now I am able to recover from my
venti backup :-)
I must confess that I am puzzled, because some sizes and most seeks
for dd are off by 1 block from what I expect. Particulary,
why do you
% dd -if arenas2.img -of arena
> that's only 98 blocks of 8192 bytes, not 128 as you mention.
Sorry, I got confused. It's 98 blocks on arena partition and
128 blocks on isect partition.
I just tried. This is what I did.
The goal is to manually recopy the first arena from
the first Venti (arenas1.img) to the second Venti (aren
There's something weird going on. First checkarenas reports
% venti/checkarenas -v /dev/da1s4
arena='arenas00' [802816,537673728)
version=5 created=1265030300 modified=1265248834 sealed
score=f383ebf9edefe8d37733c8caba6ff53e8b5517b0
clumps=82,908 compressed clumps=22,812 da
To clarify things.
You backup is correct, but it's not necessary to backup the
first 128 blocks of the arena partition. Its only contains
the Venti configuration and the ArenaPart structure.
Here is an example of what I described in my precedent message.
Create an arena partition at least as big
> It seems that the backup I create is not correct, am I right?
You truncated your arena partition. The new partition size
doesn't match the size specified in ArenaPart.
You should format a new arena partition, then copy arenas
from the beginning of the first to the end of the last.
--
David du
Just to make sure I could rebuild things in case I should, I've tried
to recover everything from my backed up arenas, but I failed. I am not
sure if things go wrong because the backup per se is wrong or I am
making a mistake while recovering from the backup (or both).
So this is how I create the ba
Great. Thanks.
I hope I will never need to use my backed up arenas :-)
2012/1/17 Steve Simon :
>> So it seems sufficient to backup my arenas, am I
>> right?
>
> Yes, exactly, I haev done this several times.
>
> It might take a few hours and some studying of manuals
> but the arenas are all you nee
> I've backed up all my *active* arenas in to another disk, just to be
> safe. The man page says that the index and the bloom filter may be
> rebuilt if lost. So it seems sufficient to backup my arenas, am I
> right?
Yes, you can rebuild the index and the Bloom filter
with 'venti/buildindex -b'.
> So it seems sufficient to backup my arenas, am I
> right?
Yes, exactly, I haev done this several times.
It might take a few hours and some studying of manuals
but the arenas are all you need.
-Steve
On Thu, 05 Jan 2012 15:03:11 EST erik quanstrom wrote:
> > > > venti doesn't have a "scrub" command, does it? zfs scrub was
> > > > instrumental in warning me that I needed new disks.
> > >
> > > they're using coraid storage. all this is taken care of for them
> > > by the SR appliance.
> >
>
erik quanstrom wrote:
> do you have a citation for this? i know if you work out the
> numbers from the BER, this is about what you get, but in
> practice i do not see this 8%. we do pattern writes all the
> time, and i can't recall the last time i saw a "silent" read error.
Yes, the real numbers
On Thu Jan 5 16:24:58 EST 2012, yari...@gmail.com wrote:
> 2012/1/5 Bakul Shah :
> > You'd save a bunch of energy if you only powered up venti
> > disks once @ 4AM for a few minutes (and on demand when you
> > look at /n/dump). Though venti might have fits! And the disks
> > might too! So may be
2012/1/5 Bakul Shah :
> You'd save a bunch of energy if you only powered up venti
> disks once @ 4AM for a few minutes (and on demand when you
> look at /n/dump). Though venti might have fits! And the disks
> might too! So may be this calls for a two level venti? First
> to an SSD RAID and a much
> You'd save a bunch of energy if you only powered up venti
> disks once @ 4AM for a few minutes (and on demand when you
> look at /n/dump).
If fossil is setup to dump to venti then it needs venti to
work at all. Fossil is a write cache, so, just after the dump
at 4am fossil is empty and consists
> > > venti doesn't have a "scrub" command, does it? zfs scrub was
> > > instrumental in warning me that I needed new disks.
> >
> > they're using coraid storage. all this is taken care of for them
> > by the SR appliance.
>
> When are you going to sell these retail?!
>
> The question was for ve
On Thu, 05 Jan 2012 13:50:48 EST erik quanstrom wrote:
> > You'd save a bunch of energy if you only powered up venti
> > disks once @ 4AM for a few minutes (and on demand when you
> > look at /n/dump). Though venti might have fits! And the disks
> > might too! So may be this calls for a two leve
On Thu, 05 Jan 2012 13:43:49 EST erik quanstrom wrote:
> On Thu Jan 5 13:26:16 EST 2012, ba...@bitblocks.com wrote:
> > On Thu, 05 Jan 2012 13:01:52 EST erik quanstrom wr
> ote:
> > > > if you read 1TB, you have 8% chance of a silent bad read
> > > > sector. More important to worry about that
> For reference, I set up our current Plan 9 system about half a year
> ago. We have 3.8 TB of Venti storage total. We have used 2.8 GB of
> that, with basically no precautions taken to set anything +t; in
> general, if it's around at 4 a.m., it's going into Venti. I figure we
> have roughly ano
but john, the whole your venti would easily fit in even a small server
memory, now and forever ;)
ron
On Thu Jan 5 14:13:55 EST 2012, ara...@mgk.ro wrote:
> >> venti doesn't have a "scrub" command, does it? zfs scrub was
> >> instrumental in warning me that I needed new disks.
> >
> > they're using coraid storage. all this is taken care of for them
> > by the SR appliance.
>
> Out of curiosity,
>> venti doesn't have a "scrub" command, does it? zfs scrub was
>> instrumental in warning me that I needed new disks.
>
> they're using coraid storage. all this is taken care of for them
> by the SR appliance.
Out of curiosity, how? ZFS blocks are checksummed. ZFS scrub reads
not physical block
> You'd save a bunch of energy if you only powered up venti
> disks once @ 4AM for a few minutes (and on demand when you
> look at /n/dump). Though venti might have fits! And the disks
> might too! So may be this calls for a two level venti? First
> to an SSD RAID and a much less frequent venti/co
> On Thu, 05 Jan 2012 10:07:08 PST "John Floren" wrote:
>>
>> For reference, I set up our current Plan 9 system about half a year
>> ago. We have 3.8 TB of Venti storage total. We have used 2.8 GB of
>> that, with basically no precautions taken to set anything +t; in
>> general, if it's around
On Thu Jan 5 13:26:16 EST 2012, ba...@bitblocks.com wrote:
> On Thu, 05 Jan 2012 13:01:52 EST erik quanstrom
> wrote:
> > > if you read 1TB, you have 8% chance of a silent bad read
> > > sector. More important to worry about that in today's world
> > > than optimizing disk space use.
> >
> >
On Thu, 05 Jan 2012 10:07:08 PST "John Floren" wrote:
>
> For reference, I set up our current Plan 9 system about half a year
> ago. We have 3.8 TB of Venti storage total. We have used 2.8 GB of
> that, with basically no precautions taken to set anything +t; in
> general, if it's around at 4 a
On Thu, 05 Jan 2012 13:01:52 EST erik quanstrom wrote:
> > if you read 1TB, you have 8% chance of a silent bad read
> > sector. More important to worry about that in today's world
> > than optimizing disk space use.
>
> do you have a citation for this? i know if you work out the
> numbers from
On Thu, Jan 05, 2012 at 10:07:08AM -0800, John Floren wrote:
>
> For reference, I set up our current Plan 9 system about half a year
> ago. We have 3.8 TB of Venti storage total. We have used 2.8 GB of
> that, with basically no precautions taken to set anything +t; in
> general, if it's around a
On Thu, Jan 05, 2012 at 09:36:13AM -0800, ron minnich wrote:
> I doubt anyone would object if you want to change the text and submit
> to the website owners.
That was my intention, but before, I wanted to submit to the list some
stuff, in order to not publish nonsense. [But probably some people eq
> if you read 1TB, you have 8% chance of a silent bad read
> sector. More important to worry about that in today's world
> than optimizing disk space use.
do you have a citation for this? i know if you work out the
numbers from the BER, this is about what you get, but in
practice i do not see th
> On Thu, Jan 5, 2012 at 10:15 AM, wrote:
>> But perhaps the other users are smart enough to have understood all this
>> at installation time, but when I first installed Plan9, that was not for
>> the archival features. And I spent my time on Plan9 looking for the
>> distributed system, the names
On Thu, 05 Jan 2012 17:39:07 +0100 tlaro...@polynum.com wrote:
> On Thu, Jan 05, 2012 at 10:44:18AM -0500, Russ Cox wrote:
> >
> > The default is that you have so little data in comparison to a
> > modern disk that there is no good reason not to save full
> > snapshots. As Erik and others have p
I doubt anyone would object if you want to change the text and submit
to the website owners.
ron
The third edition was published in june 2000. It predates
both Venti (april 2002) and Fossil (january 2003).
This documentation was about installing Plan 9 on a
standalone terminal running kfs, not a file server.
--
David du Colombier
On Thu, Jan 05, 2012 at 10:44:18AM -0500, Russ Cox wrote:
>
> The default is that you have so little data in comparison to a
> modern disk that there is no good reason not to save full
> snapshots. As Erik and others have pointed out, if you do
> find reason to exclude certain trees from the snap
On Thu, Jan 5, 2012 at 10:15 AM, wrote:
> But perhaps the other users are smart enough to have understood all this
> at installation time, but when I first installed Plan9, that was not for
> the archival features. And I spent my time on Plan9 looking for the
> distributed system, the namespace a
On Thu, Jan 05, 2012 at 02:48:10PM +0100, David du Colombier wrote:
>
> Fossil and Venti are very flexible, you can do almost
> everything you want.
No doubt about that.
But perhaps the other users are smart enough to have understood all this
at installation time, but when I first installed Plan
On Thu, Jan 05, 2012 at 09:14:28AM -0500, erik quanstrom wrote:
> > Because I use CVS (not on Plan9), and I backup my CVS. So, sources with
> > history. I do not consider CDROM to be eternal. So there is a small
> > number kept, and the older is destroyed when the new one is burnt.
>
> sorry. i t
On Thu Jan 5 08:28:57 EST 2012, tlaro...@polynum.com wrote:
> On Thu, Jan 05, 2012 at 02:20:34PM +0100, tlaro...@polynum.com wrote:
> > And finally, didn't the increase in size of the disks, with
> >no decrease
>
>
> no increase, of course. If probability of a failure for a sector i
> Because I use CVS (not on Plan9), and I backup my CVS. So, sources with
> history. I do not consider CDROM to be eternal. So there is a small
> number kept, and the older is destroyed when the new one is burnt.
sorry. i thought we were talking about organizing plan 9
storage. never mind
I am not sure to understand your question.
Nothing forces you to dump the full Fossil tree to Venti
every night. You can run snap manually every time you
want, or run it only on a part of the tree.
You can also individually exclude some files from
the snapshots using the DMTMP bit.
If you really
On Thu, Jan 05, 2012 at 08:27:50AM -0500, erik quanstrom wrote:
>
> > Secondly, I still use optical definitive storage from time to time
> > (disks go in a vault)... with KerGIS and others, and kerTeX, this still
> > fit 3 times on a CDROM. So...
>
> if you are using venti, there is no reason to
> Perhaps, but it seems to me like digging ore, extracting the small
> percentage of valuable; forging a ring; and throwing it in the ore, and
> storing the whole...
generally it's apparent which files are worth investigating, and between
history (list of changes by date) and a binary search, it s
On Thu, Jan 05, 2012 at 02:20:34PM +0100, tlaro...@polynum.com wrote:
> And finally, didn't the increase in size of the disks, with
>no decrease
no increase, of course. If probability of a failure for a sector is P,
increasing the number of sectors increases the probability of disk
f
On Thu, Jan 05, 2012 at 07:59:00AM -0500, erik quanstrom wrote:
> > So the compiled result is not worth archiving.
>
> it has been more than once that in tracking down a problem, i've
> found that the "known working" executable worked but the source
> from that point in history didn't. and vice v
> So the compiled result is not worth archiving.
it has been more than once that in tracking down a problem, i've
found that the "known working" executable worked but the source
from that point in history didn't. and vice versa. having the executables
and libraries archived was very valuable.
o
On Mon, Sep 20, 2010 at 1:34 AM, raghuveer wrote:
> I setup Venti (from plan9 port for user space) on an x86 box. When my
> program issues vtwrite( ) call, i get the following error:-
>
> vtversion /dev/fd/10: vtversion: Connection reset by peer
> vtversion /dev/fd/11: vtversion: Connection reset
> > After the reboot I can see:
> > 2010/0427 20:53:40 err 4: read /dev/sdC0/isect offset 0xe70c8000 count
> > 65536 buf 20ae000 returned 0:
> > /boot/venti: part /dev/sdC0/isect addr 0xe6c68000: icachewritesect
> > readpart: read /dev/sdC0/isect offset 0xe70c8000 count 65536 buf
> > 20ae000 return
> After the reboot I can see:
> 2010/0427 20:53:40 err 4: read /dev/sdC0/isect offset 0xe70c8000 count
> 65536 buf 20ae000 returned 0:
> /boot/venti: part /dev/sdC0/isect addr 0xe6c68000: icachewritesect
> readpart: read /dev/sdC0/isect offset 0xe70c8000 count 65536 buf
> 20ae000 returned 0:
i don
so you're completely disk bound? if disk activity on the windows
box is also low, your venti machine must be suffering.
It took just over 8 hours to copy 2.2Gb of data from an idle system to a
mostly idle system. The network is 1gbit.
So it's not maxing out the disk, not maxing out the cpu
wouldn't it suffice to set temporary permissions of 777 and fixup
when leavinging that directory?
depth first, so it could be a while in between. Not really a massive
problem but still an issue
btw. it is a great way to backup.< 1% of CPU while running, which is
doubly fortunate beca
> But when I unvac the resulting score with 9p9 [sic] on Debian it segfaults
> because 'My Documents' is dr-xr-x-- so unvac creates a read only
> directory and then tries to write into it.
>
[...]
>
> The only general purpose solution I can think of is two passes for unvac
> but that doesn't s
Thanks for the links, now everything is working (apparently), but I
have no idea what was the source of my error(s).
2010/1/29 maht :
> Hi Hugo,
>
> I did this only yesterday and am working on a backup script to go from SMB
> share on Debian -> cifs on plan9 running in Qemu on XP -> venti running
Hi Hugo,
I did this only yesterday and am working on a backup script to go from
SMB share on Debian -> cifs on plan9 running in Qemu on XP -> venti
running on Debian (the process works, just I haven't made a script yet).
http://maht0x0r.blogspot.com/2010/01/venti-on-linux-via-p9p.html
and wh
Roman Shaposhnik wrote:
> On Tue, Oct 20, 2009 at 8:53 PM, Enrico Weigelt wrote:
>> So I added several block types: eg. blob (payload data) and inode
>> (holding the tree).
>
>>From these I infer that you've build an object store, not just a block sotre.
> How close was it to this:
>http://oc
On Tue, Oct 20, 2009 at 8:53 PM, Enrico Weigelt wrote:
> So I added several block types: eg. blob (payload data) and inode
> (holding the tree).
>From these I infer that you've build an object store, not just a block sotre.
How close was it to this:
http://oceanstore.cs.berkeley.edu/publicatio
On Oct 20, 2009, at 7:53 AM, Enrico Weigelt wrote:
I've also done some bits of works in that area
(nothing usable yet ;-o), but with different
requirements:
* storage near to the user (at least local mirrors)
* equal data should get equal score (even w/ encryption)
* automatic removal of stale
Russ Cox wrote:
Hi,
> There was no real code to speak of. It was a draft of a draft.
> I did some calculations of block-level commonality using a
> few trivial programs that hashed each block of every file in
> a tree, but you could recreate that in 100 lines of C or shell script.
> We never sto
On Thu, Oct 15, 2009 at 8:32 PM, ron minnich wrote:
> Now I remember this paper. Was the code ever released anywhere?
There was no real code to speak of. It was a draft of a draft.
I did some calculations of block-level commonality using a
few trivial programs that hashed each block of every fil
Now I remember this paper. Was the code ever released anywhere?
ron
Well, since Russ is silent (and since this is not the first time this
question has come up: http://9fans.net/archive/2008/05/401) here's
a reliable link for anybody who might still be interested:
http://web.archive.org/web/20060308015519/http://project-iris.net/isw-2003/papers/sit.pdf
Thanks
> I remember Russ authoring a paper on running Venti over distributed hash
> tables,
> but I can't find the pdf anymore. All Google gives me is this:
>
> http://74.125.155.132/scholar?q=cache:6Wu_j9JaaUcJ:scholar.google.com/&hl=en
The paper you've found there was an internal MIT workshop subm
thanks for the tip. i got the same error (even the score, i think)
when i tried copying some vbackup scores to a new server a few weeks
ago. i hadn't thought of trying a different copy until you brought it
up. using plan 9's copy instead of p9p's seems to be working well
enough so far
> I thought kencc was allowed to reorder structure members, is that the case?
No.
Thanks for the answer,
In p9's venti/copy, in scoretreecmp, there are two casts, from Avl* to
ScoreTree*; this depends on scoretree's avl being the first member of
the structure; I thought kencc was allowed to reorder structure
members, is that the case?
Thanks,
-- vs
On Fri, Aug 21, 2009 at 6:15 AM, Venkatesh Srinivas wrote:
> Plan 9's venti/copy has an undocumented -m option. What does it do?
On Fri, Aug 21, 2009 at 6:23 AM, erik quanstrom wrote:
> the whole program is 262 lines long.
> i'm betting what -m does can be discovered
> by inspection.
what, maybe,
> Plan 9's venti/copy has an undocumented -m option. What does it do?
the whole program is 262 lines long.
i'm betting what -m does can be discovered
by inspection.
it might be a good idea to submit a patch
to the man page, too.
- erik
1 - 100 of 158 matches
Mail list logo
