On Thu, Mar 30, 2000 at 07:19:10PM +0530, Madhav wrote:
> Hi,
> 
> 1.Today I was trying to install postgressql under my coda. I created a user
> postgres and gave all permissions to it on a directory /coda/db, which I
> mounted for the volume dbvol, which I created under E0000104(replicated
> volume).
> When I gave the initdb command, which is trying to write something or wiping
> out, coda kept giving  the following message continuously.
> "No psedo device in upcall comms at d00626a0".
> In the venus log it gave the following message.
> "fatal error -- fsobj::discarddta:writing:executing"
> "Recovery terminated:dirty shutdown 1uncommitted transaction "

Ouch, that indicates that something in Venus tried to destroy a file
that was still open for write. Very bad. I would kill for a stacktrace
at that time.

I think it is about time to extent the CHOKE/assert code with something
that dumps a stacktrace/oops at the time of the crash.

> to my surprise under /coda/db pgsql created many files. So I tried
> creating a table. It also went fine. I will be able to run pgsql only
> if "initdb" goes through successfully. Can anyone tell me whether
> anyone tried this and if so please tell me how to get out of this?

What are you trying to do with a database in Coda? Coda won't magically
make your database replicated. These databases are commonly mmapping
large files and keeping them open for performance reasons -> updates
don't get propagated to the Coda servers. Coda provides no locking
primitives (especially hard to do when disconnected) -> potential for
concurrent writes on different clients, i.e. conflicts. And that on a
big blob of binary data. Not pretty at all.

> 2. Under coda I mounted a directory htttp for the replicated volume
> httpvol using "cfs mkm /coda/http httpvol". Later I unmounted it using
> "cfs rmm /coda/http". When I tried to mount the httpvol as /coda/http
> I got a message saying file already exists. But when I "ls", I do not
> see any file. Can't we do like this(remounting with old name after cfs
> rmm).

Which venus version? I fixed that bug the 20th of January, so it must
already have been included in the previous release (5.3.5)

2000/01/20 21:23:29    <jaharkes_at_sparta.odyssey.cs.cmu.edu>
        - After a cfs rmm the kernel wasn't told that the mountpoint is
          gone.

Jan