Re: [9fans] replica

Re: [9fans] replica

[Russ Cox]

> When I have some local change to a file, replica reports it without telling me
> what was changed in the replica server.  Sometime, I want to know what was
> changed at Labs, because I have no such solid confidence to myself in many
> case.  ;_;   
> 
> May I ask you to put the changed file of the replica server to my local disk 
> with modifying the name, say such kenji.c to kenji.c.p9bell?

i really don't want to start copying random files
around when there are conflicts.

i don't care about most of them and don't want to spend the time
downloading.

you could use this script though.

g% cat /bin/updiff
#!/bin/rc

rfork e

path = (/bin/)

d = /n/sources/plan9

if(! test -e $d) 9fs sources

for(i in $*){
	echo '=====' $i '====='
	ls -lmd $i
	switch($i){
	case /*
		diff -n $d/$i $i 
	case *
		i = `{cleanname -d `{pwd} $i}
		diff  -n $d/$i $i
	}
}
g% cd /sys/src/cmd
g% updiff tar.c
===== tar.c =====
[] --rw-rw-r-- M 8 glenda sys 12030 Feb 28 15:04 tar.c
/n/sources/plan9//sys/src/cmd/tar.c:268,269 c /sys/src/cmd/tar.c:268
< 	/* the mode test is ugly but sometimes necessary */
< 	if (dblock.dbuf.linkflag == '5' || (sp->mode&0170000) == 040000) {
---
> 	if(dblock.dbuf.linkflag == '5')
/n/sources/plan9//sys/src/cmd/tar.c:271,272 d /sys/src/cmd/tar.c:269
< 		sp->mode |= DMDIR;
< 	}
g%

Re: [9fans] replica

[Richard Bilson]

> With some guidance from Russ, I've restored
> /n/sourcesdump/2006/0824/plan9/dist/replica/plan9.^(db log) on
> sources.  pull -n at collyer.net seems to be sane again, so I hope it
> will be for everyone else.

Works for me too. Thanks very much for getting this working again.

- Richard

Re: [9fans] replica

[geoff]

jmk recovered edith's /n/other onto a new disk on Friday.  The old
disk had developed bad spots and trying to read it wedged edith,
repeatedly and with no messages.

With some guidance from Russ, I've restored
/n/sourcesdump/2006/0824/plan9/dist/replica/plan9.^(db log) on
sources.  pull -n at collyer.net seems to be sane again, so I hope it
will be for everyone else.

Re: [9fans] replica

[Martin Neubauer]

* geoff@plan9.bell-labs.com (geoff@plan9.bell-labs.com) wrote:
> Our main file server, edith, developed bad spots in its /n/other
> partition, so we took /n/other out of service until we sort it out.
> Unfortunately, a lot of the machinery that maintains sources lives
> there.  We'll be working on this problem on Friday.

No sweat. I ran a pull last night, too, and all the current situation
means is that everything gets thrown away and pulled afresh afterwards.
Not for the faint of heart though.

Re: [9fans] replica

[geoff]

Our main file server, edith, developed bad spots in its /n/other
partition, so we took /n/other out of service until we sort it out.
Unfortunately, a lot of the machinery that maintains sources lives
there.  We'll be working on this problem on Friday.

Re: [9fans] replica

[Lyndon Nerenberg]

> - What can I do to avoid this in future?

Don't Panic!

It's not just you -- I saw the same thing when I ran pull this afternoon. 
It kind of looks like Russ pushed some changes that had the side effect of 
touching a whole lot of stuff.  Or maybe was intentional -- I had to leave 
before it was done, but my that point it was already putting stuff back.

I'll try to drawterm into the server in a little while and see how it's 
doing.

[9fans] replica

[Richard Bilson]

I attempted to update my system using replica tonight, using glenda's
pull script, but as bootes and from the file server console. What
seems to have happened is that replica believed that every file ought
to be deleted. I stopped it before it made it out of /sys/src, so my
system is still usable.

Questions:

- Why?

- What can I do to avoid this in future?

- Is there an easy way to get the files resynchronized with sources?
If I try "replica/pull -v /dist/replica/network", it tells me

sys/src/9/ip/devip.c: not replicated; will not update
sys/src/9/pc/etherigbe.c: not replicated; will not update
sys/src/9/pc/fns.h: not replicated; will not update

etc.

I just realized that I didn't have a writable /tmp, so the pull would
have failed anyway, but I usually expect an error message in this
case, not devastation.

- Richard

Re: [9fans] replica

[Russ Cox]

> When pull reached /usr/glenda/lib/profile it write '... file does not exist...'
> (i remove glenda user from my system).
>
> Does it mean replica/pull broken (and some files after /usr dir not
> processed) or it's only report at end of work?

errors are reported at the end.

> Why not change 'clientroot' (in replica profile) to '/root'? It's
> should work in kfs and fossil too.

the existence of /root is a side-effect of the boot script.
i'd rather that things didn't depend on it.  also if you have
rootdir set in plan9.ini then /root and / may be very
different trees.  finally, it won't work for fossil since
we need to arrange a special non-permissions-checked
connection for people who don't like putting themselves
in group sys.

russ

[9fans] replica

[Sergey Reva]

Hello Fans

I got new installation cd, and use replica/pull
I change 'cd' profile from kfs to fossil target, and run replica/pull.

When pull reached /usr/glenda/lib/profile it write '... file does not exist...'
(i remove glenda user from my system).

Does it mean replica/pull broken (and some files after /usr dir not
processed) or it's only report at end of work?

Why not change 'clientroot' (in replica profile) to '/root'? It's
should work in kfs and fossil too.


--
http://rs-rlab.narod.ru                          mailto:rs_rlab@mail.ru

[9fans] replica

[David Presotto]

I've rebuilt rio, sam, acme, and vnc{vs} for the keyboard.h change.  I've
also rebuilt aux/vga since it was getting behind.

Make sure you've removed any spaces around = in your /lib/vgadb.  I've already
done it on the sources one.

Re: [9fans] replica

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 123 bytes --]

I think -sn would see them.  (you tell it to use the server version
to resolve conflicts, but not to update your files).

[-- Attachment #2: Type: message/rfc822, Size: 5659 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 311 bytes --]

Can replica/pull -n see the changes after I updated the changes?

I updated too many files in a long time, so I came off the desk, and did
other obligations I have for money.   If I could have some backup files
for locally changed ones, I can check it later, and give enough time to
do that...

Kenji


[-- Attachment #2.1.2: Type: message/rfc822, Size: 3889 bytes --]

[-- Attachment #2.1.2.1.1: Type: text/plain, Size: 206 bytes --]

I do a replica/pull -n to see the changes,
then I use diff or acme to look at what changed if I'm not willing
to pull them without looking first at them.

perhaps this may achieve the effect you want.

[-- Attachment #2.1.2.1.2: Type: message/rfc822, Size: 1762 bytes --]

From: okamoto@granite.cias.osakafu-u.ac.jp
To: 9fans@cse.psu.edu
Subject: [9fans] replica
Date: Thu, 4 Jul 2002 18:21:37 +0900
Message-ID: <20020704092234.344EE19988@mail.cse.psu.edu>

Don't laugh me even though I was much delayed to see replica(1). ^_^
Yeah! Replica is very nice interface to maintain and distribute solid
trees of Plan 9.   Thanks everyone who have worked for it.

I have one request here.

When I have some local change to a file, replica reports it without telling me
what was changed in the replica server.  Sometime, I want to know what was
changed at Labs, because I have no such solid confidence to myself in many
case.  ;_;   

May I ask you to put the changed file of the replica server to my local disk 
with modifying the name, say such kenji.c to kenji.c.p9bell?

Kenji

Re: [9fans] replica

[okamoto]

[-- Attachment #1: Type: text/plain, Size: 311 bytes --]

Can replica/pull -n see the changes after I updated the changes?

I updated too many files in a long time, so I came off the desk, and did
other obligations I have for money.   If I could have some backup files
for locally changed ones, I can check it later, and give enough time to
do that...

Kenji


[-- Attachment #2: Type: message/rfc822, Size: 3889 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 206 bytes --]

I do a replica/pull -n to see the changes,
then I use diff or acme to look at what changed if I'm not willing
to pull them without looking first at them.

perhaps this may achieve the effect you want.

[-- Attachment #2.1.2: Type: message/rfc822, Size: 1762 bytes --]

From: okamoto@granite.cias.osakafu-u.ac.jp
To: 9fans@cse.psu.edu
Subject: [9fans] replica
Date: Thu, 4 Jul 2002 18:21:37 +0900
Message-ID: <20020704092234.344EE19988@mail.cse.psu.edu>

Don't laugh me even though I was much delayed to see replica(1). ^_^
Yeah! Replica is very nice interface to maintain and distribute solid
trees of Plan 9.   Thanks everyone who have worked for it.

I have one request here.

When I have some local change to a file, replica reports it without telling me
what was changed in the replica server.  Sometime, I want to know what was
changed at Labs, because I have no such solid confidence to myself in many
case.  ;_;   

May I ask you to put the changed file of the replica server to my local disk 
with modifying the name, say such kenji.c to kenji.c.p9bell?

Kenji

Re: [9fans] replica

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 206 bytes --]

I do a replica/pull -n to see the changes,
then I use diff or acme to look at what changed if I'm not willing
to pull them without looking first at them.

perhaps this may achieve the effect you want.

[-- Attachment #2: Type: message/rfc822, Size: 1762 bytes --]

From: okamoto@granite.cias.osakafu-u.ac.jp
To: 9fans@cse.psu.edu
Subject: [9fans] replica
Date: Thu, 4 Jul 2002 18:21:37 +0900
Message-ID: <20020704092234.344EE19988@mail.cse.psu.edu>

Don't laugh me even though I was much delayed to see replica(1). ^_^
Yeah! Replica is very nice interface to maintain and distribute solid
trees of Plan 9.   Thanks everyone who have worked for it.

I have one request here.

When I have some local change to a file, replica reports it without telling me
what was changed in the replica server.  Sometime, I want to know what was
changed at Labs, because I have no such solid confidence to myself in many
case.  ;_;   

May I ask you to put the changed file of the replica server to my local disk 
with modifying the name, say such kenji.c to kenji.c.p9bell?

Kenji

[9fans] replica

[okamoto]

Don't laugh me even though I was much delayed to see replica(1). ^_^
Yeah! Replica is very nice interface to maintain and distribute solid
trees of Plan 9.   Thanks everyone who have worked for it.

I have one request here.

When I have some local change to a file, replica reports it without telling me
what was changed in the replica server.  Sometime, I want to know what was
changed at Labs, because I have no such solid confidence to myself in many
case.  ;_;   

May I ask you to put the changed file of the replica server to my local disk 
with modifying the name, say such kenji.c to kenji.c.p9bell?

Kenji

Re: [9fans] replica

[Russ Cox]

> the advantage of keeping a hash (eg, md5 or sha1) is that it distinguishes
> contents of files, which usually is what really matters,
> whereas modification times and file length by themselves
> aren't really adequate (in general, in my experience).

> in short, i thought the use of hash values in wrap was a good idea
> and was surprised it wasn't part of replica!

i may well have dropped the ball on this one.
i'm still not sure.  replica was written only
for the distribution and as such i had little
experience with it before sending it into battle.
originally i used only mtimes and thought that
having the local metadata kept by the file system
was a feature, so you could play games if you knew
what you were doing.  then i got talked into using lengths
too (and rightfully so), and at that point i should
probably have tossed in the hash.
at this point it's hard to add fields to the database
and the log, since the current replica tools won't
like that.

i originally planned to use tra but it was clear that
tra wouldn't be solid enough by the time it was
needed.  once i understand things better i may set
up tra as an alternate way to get updates.  what i like
best about tra is that it's completely general.

with replica you have to declare a server to be the single
point of truth, and if you try to chain things (e.g.,
you try to grab updates using a different machine as
server, or vita nuova adds or tweaks some files) then
you have to be careful, because in general you can't
just grab updates from any other machine and expect everything
to work.

if we were using tra, you could install a new system
using any other plan 9 system you had available on the
network, and it would still be safe to go back to
sources for updates.  i still want to see what that
would be like, but it won't happen until the fall.

russ

Re: [9fans] replica

[forsyth]

>>Then you have to spend time downloading the
>>remote file when most of the time you're going to throw it away
>>because the local file _has_ been locally modified.
>>I could have included sha1 hashes in the replica(8) metadata.
>>Oh well.  I expected this not to happen very often,
>>and so far have not been proved wrong.

the advantage of keeping a hash (eg, md5 or sha1) is that it distinguishes
contents of files, which usually is what really matters,
whereas modification times and file length by themselves
aren't really adequate (in general, in my experience).  Qid.path and Qid.vers
might do i suppose, but are unique to Plan 9, and even they can change
when the contents of a file hasn't actually changed.  the hash makes it easier
to track versions historically (eg, if i have a file with a given hash code,
i can check distribution packages or logs to see whether that file was
ever actually distributed as it stands, and if so, when).  similarly,
if i've got an external replica, i can also use
the hash values to relate it to the contents of a (worm) file system dump.
there is a risk with hashing of false hits, but perhaps venti suggests
that people can be relaxed about that if the hash is peculiar enough.

in short, i thought the use of hash values in wrap was a good idea
and was surprised it wasn't part of replica!