On Thu, 21 Jan 1999, Peter J. Braam wrote:
> Holding databases in a distributed file system requires locking. Coda has
> no facility to do this. Sorry you'll have to use another system.
>
> For true redundancy you should look into a replicated database, since
> there is more to it that merely
Wolfram,
Holding databases in a distributed file system requires locking. Coda has
no facility to do this. Sorry you'll have to use another system.
For true redundancy you should look into a replicated database, since
there is more to it that merely replicating the log and data file.
- Pete
On Wed, 20 Jan 1999, Troy Benjegerdes wrote:
> Correct me if I'm wrong, but both AFS and coda keep data on the servers
> (in the RVM data file??) which allow one to recover files from 24 hours
> ago. My univerisity has AFS, and I have recoved files I accidentally
> deleted a couple of times like
Troy wrote:
> Correct me if I'm wrong, but both AFS and coda keep data on the servers
> (in the RVM data file??) which allow one to recover files from 24 hours
> ago. My univerisity has AFS, and I have recoved files I accidentally
> deleted a couple of times like this. I also recall reading in one
> In other completely different news, I tried compiling coda on my Alpha and
> I got laughed at by my compiler...
>
> The first minor choke was in lib-src/lwp.c at line 552:
>
> if ((int) stackptr == -1)
>
> stackptr is originally typed as (char *)...in Alpha-land, pointers are 8
> bytes
> >
> > Whoops, this is a good point. However, the conflict resolution mechanisms
> > themselves would use the chunk fetching code, so it need not really be a
> > problem.
>
> The problem situation I was thinking of was this: Client1 is connected,
> and retrieves the middle chunk of a file. A
On Wed, 20 Jan 1999, Jason Duerstock wrote:
> Perhaps some sort of watermark could be set for what is acceptable to
> cache as a whole file and what is not?
Um, easiest solution would be to cache whole files when they're being
written to, since typically (i.e. non-dbm case) you write the whole
fi
Perhaps some sort of watermark could be set for what is acceptable to
cache as a whole file and what is not?
In other completely different news, I tried compiling coda on my Alpha and
I got laughed at by my compiler...
The first minor choke was in lib-src/lwp.c at line 552:
if ((int) st
On Wed, 20 Jan 1999, Peter J. Braam wrote:
> > AFS deals with this by 'chunking' -- that is, it demand-loads portions of
> > files into the cache as they are needed; I believe it also uses an
> > agressive read-ahead policy. The net result is more efficient use of the
> > cache for partial file
On 20 Jan 1999, Magnus Ahltorp wrote:
> > It's a good puzzle to see if Coda's connected semantics allow for the
> > atomic creation of a lock file. Perhaps that is just possible. On the
> > other hand, I don't really have much more faith in AFS or NFS without lock
> > daemons when it comes to my
> It's a good puzzle to see if Coda's connected semantics allow for the
> atomic creation of a lock file. Perhaps that is just possible. On the
> other hand, I don't really have much more faith in AFS or NFS without lock
> daemons when it comes to my mail.
There are advisory locks in AFS, so mai
On Wed, 20 Jan 1999, Robert Watson wrote:
> On Wed, 20 Jan 1999, Laszlo Vecsey wrote:
>
> > Isnt part of the problem the client, which afaik is not supposed to have a
> > large cache, say greater than 300mb or so.
>
> My understanding was that part of the problem lies in the scalability of
>
This would be for one server. You could have many of course that enter
the /coda name space transparently.
On Tue, 19 Jan 1999, Troy Benjegerdes wrote:
> On Tue, 19 Jan 1999, Peter J. Braam wrote:
>
> > Where will the limits lie? I think that I can see that we can scale Coda
> > to approximat
On Wed, 20 Jan 1999, Laszlo Vecsey wrote:
> Isnt part of the problem the client, which afaik is not supposed to have a
> large cache, say greater than 300mb or so.
My understanding was that part of the problem lies in the scalability of
RVM as a transaction system; because it mmaps its log into
On Tue, 19 Jan 1999, Troy Benjegerdes wrote:
> On Tue, 19 Jan 1999, Peter J. Braam wrote:
>
> > Where will the limits lie? I think that I can see that we can scale Coda
> > to approximately 500,000 files over the next year (the size of the files
> > is irrelevant). There will be implementation
On Tue, 19 Jan 1999, Peter J. Braam wrote:
> Where will the limits lie? I think that I can see that we can scale Coda
> to approximately 500,000 files over the next year (the size of the files
> is irrelevant). There will be implementation changes needed for that which
> are not backward compati
On Tue, 19 Jan 1999, Peter J. Braam wrote:
> Where will the limits lie? I think that I can see that we can scale
> Coda to approximately 500,000 files over the next year (the size of
> the files is irrelevant). There will be implementation changes needed
> for that which are not backward compati
17 matches
Mail list logo
