On Sat, Jul 31, 2004 at 06:45:18PM +0400, Igor Yu. Zhbanov wrote:
> There are two Linux file servers: master and reserve. We need to store about
> 180 GB of data in about of 130000 files. Also there are about 10 - 15 Windows
> clients.
> 
> The current idea is to create Coda file system on Linux servers and make
> (probably read-only) replication from master server to reserve server.

You mean probably "two servers and two clients on the same machines".
I would rather recommend putting the clients separately. You may even be
better off using one server and one client (and possibly a spare client
to be able to move your samba server to it if the first client becomes
unavailable). Server downtime would not be devastating as the client would
have most of the relevant files in its cache, and be able to serve them to
the clients.

[There is no such thing in Coda as read-only replication (it used to be
but it does not have much sence)]

> On master server Samba server will be running over /coda directory. So Windows
> clients can easily use ordinary network drives to access to shared files.

There are some inherent problems with Coda file access via samba from
Windows clients. Jan har commented it in detail some time, search the list.
On the other side, if your clients do not access the same file at the same
time, you might be fine.

> Since we have all files replicated on reserve server, when main server crashes,
> we can easily reconfigure reserve server (shutdown crashed main server, change
> reserve server's IP-address, run Samba on reserve server). So reserve server

(I think, in cifs there are some provisions for failover replication, too...?)

> continue work as normal (except of that changes files was open during crash
> will be not be replicated, since replication in Coda, as I know, is done after
> file was closed).

The replication can be delayed a lot more, until some client tries to access
the data _and_ all servers are available.

> 1) Is it possible? What is good and what is bad?

see above

> 2) Is coda transfers the whole changed file from server to server? I mean if
>    I will change 1 byte of 100 MB file will Coda transfer 100 MB or just few

It will transfer 100Mb (even more between the servers)

>    bytes? And is it possible to use another transfer means (such as rsync
>    [rsync.samba.org] which transfers only difference between files).

Not as a Coda transport protocol.

> 3) Is Coda capable to store 180 GB of data on single machine?

Yes, unless the number of file is not too big
(your 130000 files shouldn't be a problem)

>  Should data   partition be splitted into smaller partitions?

Doesn't matter for Coda.

> 4) As I know RVM data is about of 4% of total data size. So, in our case RVM
>    data will be 7.2 GB. Can we run Coda on a machine with 1 GB of system
>    memory? (I hope, Coda does not need ALL RVM data to be resided in memory?)

You cannot have more than about 1Gb RVM. All of that has to reside in the
virtual memory simultaneously. On the other side, you do not need as much
for 130000 files. See the archives on how to calculate approximate RVM
usage.

> 5) Should we use read-only replication from main server to reserve server,
>    since no one will touch files on reserve server until the main server
>    crashes?

You do not "touch files on a server", you do "access files on Coda",
and coda internals decide how and when which data is updated.
Your Samba server has to be a _Coda_client_, which will talk to both
Coda servers.

>    disconnected from network and reserve server will be "renamed" to main.

You do not want to rename a Coda server. You do not need that either.

> can
>    reserve coda server function when SCM server is shut down?

Yes.

> 7) Does Coda backup utilities stores changed file in incremental backup as a 
>    whole or changes from previous version only?

It can do either.

> Can we make backup by backing
>    up /vice and /vicepa directories directly by third-party utilities (such as

If you reinstall the whole or nothing, then yes, on a perfectly quiet system.
Otherwise probably no. If you want per-file restore, then definitely no.

> 8) Ideally we need a script that keeps one week old full backup and 6
>    incremental backups. And when it adds one more incremental backup, it first
>    merges full backup with oldest incremental backup and remove unneeded one.
>    So we always have 1 full and 6 incremental dumps for the last 7 days. Can
>    we make this with your utilities or we need to write own?

I think it is rather hard job, merging a full beckup with an incremental one.
You would probably need an on-disk copy of the whole data.
You will certanly have to write some scripts.
(And I'm afraid it will run out-of-sync as time goes.)

Regards,
--
Ivan