Coda File System

Re: partitions and partition sizes

From: Patrick Walsh <>
Date: Mon, 04 Apr 2005 09:55:14 -0600

	Thanks for the very helpful replies.  I have a few points that I'd like
to double-check.

> > 	Our total storage need in coda will be around 40gb.
> Then you want to run rvmsizer to check - probably you will be fine with
> one server process, then use the maximal rvm size available, 1G.

	rvmsizer suggests a rvm size of 70mb (and that's with a little cushion
added by me).  Would you recommend bumping it up to 500mb or 1G anyway?
Note that these machines have 1GB of RAM and if the RVM must reside in
memory, then it seems that it ought to be smaller than 1GB (provided the
number of files and directories is sufficiently small).  Is that the
correct thinking?  Or is the RVM metadata information no longer
completely mapped into memory?

> volume "/important/data/version/1" to be mounted on
> /coda/your.realm/important/data/version/1 created by
> "cfs mkm /coda/your.realm/important/data/version/1"

	So volumes are completely arbitrary and should be kept small.  Is there
a rule of thumb regarding how small?  At what point is there a
performance hit?  Is extra administration required to manage more

> > * Second: I think I remember reading something about avoiding ext3.  Is
> > that for the actual files?  Or just for rvm metadata and logs?  
> It is no problem nowadays.

	Since I'm creating a partition just for file data for coda, is there a
best-performing fs type to use?  ext2 or ext3?  Or does it make
absolutely no difference?

> No. There is no reason to prefer partitions to files any more.

	That makes things far easier.  Someone should update the docs and the

	Thanks for the help.  I'm on my third test rollout of coda and I'm
getting a better handle on what I'm doing.  At some point I'll be back
here with questions about backing up.  I'm a bit unclear as to why
standard dump type utilities can't be run on a /coda filesystem.  Also,
I thought that having multiple replicating servers provided automatic
backup.  But I'm not ready to tackle these questions fully just yet...

	Thanks again, your response was a big help.

Patrick Walsh
eSoft Incorporated
303.444.1600 x3350

Received on 2005-04-04 11:57:56