headers
Andrey S. Kukhar | 1 Aug 2003 03:20
Picon

Re: Bug Report: snoopy & system load

where you get this P2 133MHz?

	kyxap

> Hi,
>
> Since there isn't any sort of place to register bugs and
> such I thought I'd pass it along.
>
> snoopy will throw 'read exceptions' during a pull on a P2
> 133MHz with 128M of RAM. The pull seems to go fine but
> snoopy seems to have a problem after about 2-3 minutes of
> operation.
>
> I've run snoopy on this exact same machine for days on
> end withou a hitch on several previous occassions.
>
>
>  --
>    
> _________________________________________________________
>___________
>
>       We are all interested in the future for that is
> where you and I are going to spend the rest of our lives.
>
>                               Criswell, "Plan 9 from
> Outer Space"
>
>       ravage <at> ssz.com
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jim Choate | 1 Aug 2003 01:19

Re: Bug Report: snoopy & system load


On Thu, 31 Jul 2003, Dan Cross wrote:

> > Since there isn't any sort of place to register bugs and such I thought
> > I'd pass it along.
>
> 9trouble <at> plan9.bell-labs.com

Thanks. I'll be adding a second one since the pull I started this AM
failed at some point during the day. It failed just after
sys/src9/ppc/ucu.h with an error about bin/fscmd directory entry not
found. Then a line about /n/kfs/disk/replica/client/_plan9.db: rc(pull):
can't open: access permission denied.

<shrug>

Onward through the fog.

 --
    ____________________________________________________________________

      We are all interested in the future for that is where you and I
      are going to spend the rest of our lives.

                              Criswell, "Plan 9 from Outer Space"

      ravage <at> ssz.com                            jchoate <at> open-forge.org
      www.ssz.com                               www.open-forge.org
    --------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jim Choate | 1 Aug 2003 01:20

Re: Update account


On Thu, 31 Jul 2003, David Presotto wrote:

> They are ready as soon as you add them.

I can say definitely that pull accounts are -not- ready as soon as you add
them. I've had to wait at least an hour in every case and sometime a day
or so. I'm not the only one who has noticed this behavior.

 --
    ____________________________________________________________________

      We are all interested in the future for that is where you and I
      are going to spend the rest of our lives.

                              Criswell, "Plan 9 from Outer Space"

      ravage <at> ssz.com                            jchoate <at> open-forge.org
      www.ssz.com                               www.open-forge.org
    --------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Jim Choate | 1 Aug 2003 01:28

Re: CDROM boot failed, how can i do?


On Thu, 31 Jul 2003, andrey mirtchovski wrote:

> because 9load cannot find your cdrom drive. as others suggested:
>
> 	- try switching its place -- if it's on the second ide slot move it to
> 	  the first, if on the first -- move it to the second
> 	- try it without the hard drive in
> 	- try a floppy disk
>
> experiment.

I agree with the "experiment" part, my suggestion would be a lot more
organized with your approach than others would suggest. I'd say -never-
put your CD drive as a slave on a EIDE (or IDE for that matter), unless
you're sure you'll -never- want to boot from it. I'd suggest strongly that
if you put your CD on master and your HD on the slave and it still doesn't
see the CD drive then get another CD drive. There are some problems with
some drives (I've got a pile of about four drives that don't work). I just
replaced the drive in saucer.ssz.com with a DVD/CD burner and it worked like
a champ (the 40G drive helped a lot too).

> the documentation is on the plan9.bell-labs.com/plan9dist web page, see
> Papers, Man pages and Wiki.

As an aside, Rob and I have been working on a new install doc that makes a
lot more sense than the stuff on the Bell Labs site, too much work
scattered out over too many documents.

http://einstein.ssz.com/hangar18/Plan9Intro.txt
(Continue reading)

Permalink | Reply | 2 comments |
headers
Geoff Collyer | 1 Aug 2003 01:36

Re: 9p & read-ahead

Ken's file server does read-ahead and write-behind, so there's good
solid precedent.
Permalink | Reply | 0 comments |
headers
Jim Choate | 1 Aug 2003 01:37

Re: Bug Report: snoopy & system load


On Thu, 31 Jul 2003, David Presotto wrote:

> I'll check it out.  I'm assuming an ethernet connection?

My setup is that I have a local 10/100 Ethernet. There are 6-8 machines on
it at any given time of various OS'es (eg Win, Linux, Plan 9, AmigaDOS,
Unununium, SkyOS, etc.). This network gateways through a ISDN
bridge/router to another bridge/router that sits on another persons
internal network. That internal network is gatewayed into a T1. The
nameserver for all the machines is on the T1 side.

My personal guess, since snoopy is throwing read errors, is that there is
a locking issue between pull and snoopy getting access to some buffer or
stack somewhere. It bops along for some indeterminate but reasonably short
period (I'd say none of the fails I've seen take more than 10m to catch)
snoopy will throw the exception and drop you back to the cli.

 --
    ____________________________________________________________________

      We are all interested in the future for that is where you and I
      are going to spend the rest of our lives.

                              Criswell, "Plan 9 from Outer Space"

      ravage <at> ssz.com                            jchoate <at> open-forge.org
      www.ssz.com                               www.open-forge.org
    --------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
okamoto | 1 Aug 2003 03:15
Picon

Re: Venti for Fossil

>> [...] a lot of the fossil internals and the venti library code
>> it uses are not loved very much.
> 
> i blame all that mixed case...

I lean to Jim's stand, because file server is the heart of
Plan 9 system, and we expect most robustness to it,
most deeply thinked, and most finest codes it comprises.
All those beyond my ability, and I expect someone can
do it for us.    What I can give them?   Only my respects to them.
I'm sory for all...

Anyway, now I know the present status of venti+fossil,
and I'll touch it with most careful attention from now.
I'll continue to try to live with this venti+fossil and old robust
and loved file server in our Plan 9 network.

Kenji
Permalink | Reply | 11 comments |
headers
Dan Cross | 1 Aug 2003 03:27
Picon
Favicon

Re: Venti for Fossil

> Anyway, now I know the present status of venti+fossil,
> and I'll touch it with most careful attention from now.
> I'll continue to try to live with this venti+fossil and old robust
> and loved file server in our Plan 9 network.

Yeah, I haven't switched over yet either because it seems like venti
and fossil are still getting some of the kinks worked out, and I can
live with the limitations of Ken's fileserver.  Once things stabilize
a bit more, I'll switch.

	- Dan C.
Permalink | Reply | 0 comments |
headers
Joel Salomon | 1 Aug 2003 04:45
Favicon

compare-by-hash

> I assume you think Venti does compare-by-hash, but it doesn't.

Actually, I was responding to the unanswered question of a month ago - 
how concerned do we need to be about hash collisions? Answer: not very. 
Even at the petabyte and exabyte levels, these would be vanishingly unlikely.

(BTW, are there 'standard' prefixes for higher ranges than exa- ? *Very* 
important to be able to say when SHA-1 will start having problems :-)

--Joel
Permalink | Reply | 6 comments |
headers
Geoff Collyer | 1 Aug 2003 04:52

Re: compare-by-hash

Some new prefixes were blessed in 1991.  Yotta (appreviated `Y') is
10⁲⁴, Zetta (`Z') is 10⁲ⁱ.  In the other direction, beyond
pico, femto and atto, zepto (`z') is 10⁻⁲ⁱ, yocto (`y') is
10⁻⁲⁴.  http://www.unc.edu/~rowlett/units/prefixes.html has the
whole story.
Permalink | Reply | 5 comments |

Gmane