[9fans] big pull

[9fans] big pull

[Russ Cox]

The next pull will be a big one.
Due to various changes in the C library,
basically all the system binaries changed,
so it seemed like a good time to sync up.

Russ

Re: [9fans] big pull

[Lucio De Re]

On Mon, Jun 23, 2003 at 06:35:14AM -0400, Russ Cox wrote:
>
> The next pull will be a big one.
> Due to various changes in the C library,
> basically all the system binaries changed,
> so it seemed like a good time to sync up.
>
Russ,

will you release a new ISO image at the same time, please?  With a
release identifier in it?

I'm a little lost here with the number of versions that I have
managed to accumulate, and a final issue would have a very salutary
effect.

My biggest problem, sadly, is that I don't seem to be able to bring
the base system up to speed.  After a pull update from a CD-ROM
image I generated myself, a "diff -r" between the source and
destination yields quite a lot of discrepancies :-(

If one can't be sure of having a consistent system (which could be
caused, of course by a number of anomalies, for example, I had an
empty /sys/src/9/pc/apic.c on the Fossil server :-( then things
get a bit rough.

I'm not sure how one goes about sanity checking the system, but it
would be good if replica had a tool to do something of a check.
Hm, maybe it does, but not explicitly.  I'm a lazy person and fail
to see things that are not spelled out to me.

++L

PS: And thanks to you and all the team contributors for your efforts
and all the benefit you have bestowed on us.  To paraphrase a trite
cinema character: "We're not worthy!"

PPS: I meant to ask you this a while back, but keep treating it as
not important enough to warrant a separate mail message: where is
the U9FS source that has been released separately?  Is a link to
it from the Plan 9 pages not perhaps warranted?

Re: [9fans] big pull

[Lucio De Re]

On Mon, Jun 23, 2003 at 12:49:04PM +0200, Lucio De Re wrote:
>
> On Mon, Jun 23, 2003 at 06:35:14AM -0400, Russ Cox wrote:
> >
> > The next pull will be a big one.
> > Due to various changes in the C library,
> > basically all the system binaries changed,
> > so it seemed like a good time to sync up.
> >
> Russ,
>
Ah, well, I guess I didn't embarrass myself, or Russ, excessively!

++L

Re: [9fans] big pull

[Joel Salomon]

On Mon, 23 Jun 2003, Russ Cox wrote:
> Due to various changes in the C library,

Were these changes anything interesting, or just bug fixes?
--Joel

Re: [9fans] big pull

[boyd, rounin]

> Were these changes anything interesting, or just bug fixes?

i'm pretty sure they incorporated the *BSD trees into plan 9,
but i could be wrong ...

Re: [9fans] big pull

[Joel Salomon]

> > Were these changes anything interesting, or just bug fixes?
>
> i'm pretty sure they incorporated the *BSD trees into plan 9,
> but i could be wrong ...
>
If you're suggesting what I think you are, I sincerely hope so ;-)

--Joel

Re: [9fans] big pull

[Russ Cox]

> Were these changes anything interesting, or just bug fixes?

no, i just lost track of why various things had changed.
probably libfmt.  it's always libfmt.

Re: [9fans] big pull

[Russ Cox]

Wait a day or two and then download the "Sources Snapshot"
from the updates page, which gets updated nightly (by 6am
EST).

The u9fs distribution is also on the updates page.

Russ

Re: [9fans] big pull

[okamoto]

>> Were these changes anything interesting, or just bug fixes?
>
> no, i just lost track of why various things had changed.
> probably libfmt.  it's always libfmt.

I've been happy with the last (end of May or June) libfmt...

Kenji

Re: [9fans] big pull

[Russ Cox]

> > no, i just lost track of why various things had changed.
> > probably libfmt.  it's always libfmt.
>
> I've been happy with the last (end of May or June) libfmt...

that's the worst part -- it's usually some corner case
of libfmt that will never run anyway but is worth fixing.

but this one was actually malloc, again a corner case
that will likely never run anyway -- i changed the debugging
to check for bad blocks in a better order.  i messed up
on this one.  i should have staged it better to avoid
recreating all new binaries.  but what's done is done.
i usually do better.

that was a busy day.  grep '^1055' /dist/replica/client/plan9.log

Re: [9fans] big pull

[okamoto]

By the way, the problem reported by Nemo before of fossil's
memory leak has been fixed in the big pull?   Or the problem
was not recognized?

I may have time to build venti/fossil for our site within a few
weeks, yeah! Summar vacation without students is comming soon!

Kenji

Re: [9fans] big pull

[Fco.J.Ballesteros, nemo]

> By the way, the problem reported by Nemo before of fossil's
> memory leak has been fixed in the big pull?   Or the problem
> was not recognized?

The incrase in memory size is not too much. When it runs enough days,
the increase in size is comparable to that of cs and some other programs.

Here are some numbers for a certain number of days.

I didnt trace where the memory went, though.

#!/bin/rc
# w swapstats
cat $0 | grep '^[0-9]' | awk -F/ '{print $1}' | graph -a | plot
exit ''
53150/110163 memory 0/160000 swap
53350/110163 memory 0/160000 swap
53857/110163 memory 0/160000 swap
54082/110163 memory 0/160000 swap
54583/110163 memory 0/160000 swap
54735/110163 memory 0/160000 swap
54701/110163 memory 0/160000 swap
54756/110163 memory 0/160000 swap
54810/110163 memory 0/160000 swap
54870/110163 memory 0/160000 swap
54791/110163 memory 0/160000 swap
54893/110163 memory 0/160000 swap
55006/110163 memory 0/160000 swap
55096/110163 memory 0/160000 swap
55095/110163 memory 0/160000 swap
55146/110163 memory 0/160000 swap
55304/110163 memory 0/160000 swap
55283/110163 memory 0/160000 swap
55368/110163 memory 0/160000 swap
55458/110163 memory 0/160000 swap
55504/110163 memory 0/160000 swap
55574/110163 memory 0/160000 swap
55609/110163 memory 0/160000 swap

Re: [9fans] big pull

[Lucio De Re]

On Wed, Jun 25, 2003 at 09:48:22AM +0200, Fco.J.Ballesteros wrote:
>
> The incrase in memory size is not too much. When it runs enough days,
> the increase in size is comparable to that of cs and some other programs.
>
Could this not be the accumulation of output to /srv/fscons?

Just wondering...

++L

Re: [9fans] big pull

[Lucio De Re]

On Wed, Jun 25, 2003 at 10:01:18AM +0200, Fco.J.Ballesteros wrote:
>
> Hmm, I keep a window running a con to /srv/fscons. IIRC, that drains
> the output queue for the console.

That's what I was wondering about.  So it's not the obvious cause.

++L

Re: [9fans] big pull

[Fco.J.Ballesteros, nemo]

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

Hmm, I keep a window running a con to /srv/fscons. IIRC, that drains
the output queue for the console.

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

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] big pull
Date: Wed, 25 Jun 2003 09:50:25 +0200
Message-ID: <20030625095025.U2250@cackle.proxima.alt.za>

On Wed, Jun 25, 2003 at 09:48:22AM +0200, Fco.J.Ballesteros wrote:
>
> The incrase in memory size is not too much. When it runs enough days,
> the increase in size is comparable to that of cs and some other programs.
>
Could this not be the accumulation of output to /srv/fscons?

Just wondering...

++L

Re: [9fans] big pull

[Richard Miller, miller]

term% wc /dist/replica/client/plan9.log
  12732  127320  947058 /dist/replica/client/plan9.log

Does this log ever get truncated or does it grow without bounds?

Re: [9fans] big pull

[Russ Cox]

> Does this log ever get truncated or does it grow without bounds?

It gets truncated occasionally.  There's a target
in /sys/lib/dist/mkfile if you're interested.

Russ

Re: [9fans] big pull

[Russ Cox]

> By the way, the problem reported by Nemo before of fossil's
> memory leak has been fixed in the big pull?   Or the problem
> was not recognized?

Reproduce it and run leak, please.  Until then,
there's little we can do.

Russ

Re: [9fans] big pull

[Fco.J.Ballesteros, nemo]

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

As I said in a previous mail, I think there's actually no real problem.
After a few days fossil does not grow more than other programs.

I'm sorry if I didnt make it clear before.

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

From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] big pull
Date: Wed, 25 Jun 2003 21:59:47 -0400
Message-ID: <050b40a7e24813021540a00585ab200f@plan9.bell-labs.com>

> By the way, the problem reported by Nemo before of fossil's
> memory leak has been fixed in the big pull?   Or the problem
> was not recognized?

Reproduce it and run leak, please.  Until then,
there's little we can do.

Russ

Re: [9fans] big pull

[Richard Miller, miller]

>> Does this log ever get truncated or does it grow without bounds?
>
> It gets truncated occasionally.  There's a target
> in /sys/lib/dist/mkfile if you're interested.

I see - very neat.  I was worried that everyone would have to
synchronise with sources before you could safely truncate the log.
But of course you only need to maintain the most recent event
for each file.