Yes I am using qmail and courier and everything is in
Maildir format. The big problem now is the size of
the RVM. If I broke down the monolithic servers into
smaller ones of 50gb each, and replicate each one of
those internationally I wonder if it would work.
--- [EMAIL PROTECTED] wrote:
> On
On 11 Oct, Zachary Denison wrote:
>
>
> In terms of the read any/ write all strategy thats
> exactly what I want. I do want it to deliver ail to
> all the servers at once. I want a system exactly as
> yuo said, so that if one location completely loses
> internet connectivity, users outside tha
In terms of the read any/ write all strategy thats
exactly what I want. I do want it to deliver ail to
all the servers at once. I want a system exactly as
yuo said, so that if one location completely loses
internet connectivity, users outside that location can
still access the email. Coda see
On Wed, Oct 10, 2001 at 10:02:19PM -0700, Zachary Denison wrote:
> drive, where I store users mail directories. What I
> would like to do is setup these three machines as CODA
> servers with replication, so each one is an exact
> mirror of the other 2. Is this what happens under
> replication?
geographically
disparate locations. At each location I want to have
CODA clients, which run the mail delivery software.
Anyway my question is that, is it possible to have
coda with such large servers, because, as I am reading
the administration manual, it seems to imply that the
maximum size of the RVM log
"Tomalla, Wolfram" <[EMAIL PROTECTED]> ,in message <44392638B0B9D011B713C09541E0
2AC7DD@procomres1>, wrote:
> The problem is thee are no replicated Databases that realy
> hold the Data faliles except Oracle. And an Oracle
> istallation would cost us $25.000 - $30.000 per system.
> Al
Hi again,
The problem is thee are no replicated Databases that realy
hold the Data faliles except Oracle. And an Oracle
istallation would cost us $25.000 - $30.000 per system.
All the other Databases actualy only support a warm standby.
That means, if the Database commited a transaction, the
dat
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
Hi,
I'm from a company in germany that produces a controling
system for a lot of different processes eg. a powerplant
or a central controling of Coce mashines.
I thought about running a database (with ODBC and JDBC
drivers) on a coda filesystem to get a redundant data
holding. I think the proble
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
Folks,
We are getting a lot of requests for people wanting to run larger Coda
servers. Basically the answer is: we don't think it will work yet.
The content of this message is roughly as follows:
- where will the limits lie in the nearish future
- this release of Coda is a little different
- w
26 matches
Mail list logo
