Coda File System

Re: New work on Coda for Summer 2011

From: Paulo Casanova <>
Date: Thu, 16 Jun 2011 20:21:47 +0100
Hi Phil,

I'm going to answer your questions but first let me add a few initial comments:
1. This is exactly how I'm accessing coda on my Windows machine
(through an SMB mount of venus) so I can say the approach works rather
2. For "honesty"'s sake (and don't take this offensively!) don't mix
this with a port for Windows. Saying running coda on a VM brings coda
to Windows is like saying I have MS Office on Linux because I have a
VM with Windows XP :)
3. My experience with VMs (and I have some but I'm sure there are
people in this list who have a lot more) is that they come with a
rather heavy cost of CPU compared to the "native" thing. I'm not sure
if you can get a stripped down Linux which is so lightweight that
won't be noticeable. I don't talk about RAM because it can work well
with a relatively low amount of RAM. But CPU overhead is definitely
4. You may run into problems managing disk space. Virtual hard drives,
AFAIK, can grow but they don't shrink easily (you have to defrag, shut
the VM down and compress which takes a long time). Which means your VM
will take the maximum size of the venus cache and you can't get that
back. This may be relevant or not depending on how much cache you need
but I have around 100Gb :)

Neither of these comments mean it won't work. They just mean the use
case scenarios should be clear :) What kind of usage are you aiming

Now, about your questions... please prefix all my answers with IMHO :)

>    1) What would be the best approach to building the appliance?  Start
> with a small distribution like "TinyCore Linux" and add content to get
> a working Coda appliance or start with a large distribution like Debian
> and delete unneeded contents to make a smaller machine.  We are currently
> considering using Debian as the base and producing a minimal installation
> without gnome.

TinyCore Linux. A standard debian server install -- without X -- takes
around 2Gb IIRC. Well, maybe less, I had to install a few extra things
last time I did it :) but definitely over 1Gb.

>    2) How important is the desktop on the appliance?  Is the assumption
> that all it would be used for is just the coda utilities (clog, codacon,
> and so forth) or would a fully functional Linux VM be the better way
> to go with Gnome and all that it offers?   (A full Gnome installation
> would cause a much larger VM image similar to the test appliance listed
> above.)

Don't add a UI. Coda can't be controlled graphically and you're just
wasting disk space, CPU & RAM. You can just login into the VM (or SSH
into the VM if you configure network correctly).

>    3) Plans are currently to have the appliance just have a guest account
> with no password.  The user (again we are assuming a single user machine)
> just uses the VM console to clog to their proper Coda user and the
> host machine gets access via the guest account.  Thus, no account creation
> is needed on the appliance.   This does give every user on the host machine
> common access to the Coda appliance.   Does this sound reasonable?  Do you
> see a need for appliance accounts?

Well, this is tricky (but you figured that out already I guess). But I
guess other solutions are more complicated... and your use case
scenario seems to be as a Workstation. Otherwise you wouldn't be
discussing Windows XP/Vista/7, right? And I imagine most workstations
nowadays are single user...

>    4) Although current plans are to have clog, cfs, repair and so forth
> available only on the appliance console, would people like to see a native
> app/script that brings clog and friends to the host desktop?

It would definitely simplify usage. As long as people have cygwin, I
guess a simple bash script (based on SSH) would do that easily. If you
like you can try, errr, powershell? DOS? :)

>    5) How important is having storage space available for the "user" in
> the appliance.  The proof of concept appliance has 300Megs of user storage
> available.  Is this too much or not enough?

Put a large virtual drive with a default cache size configured in
venus.conf. There is not much to loose. If the user wants a larger
virtual drive they can just increase the size in venus.conf. If they
want a smaller size, they just decrease it in venus.conf (as long as
they haven't filled the cache yet). What is there to win if you limit
the size of the virtual drive?

>    6) Would people find it useful to have a choice of a small, no gnome
> appliance with limited user space (the goal is to have 500Megs or smaller
> total appliance) and a large, full gnome installation with 4G (or more)
> virtual disk available for user use? (e.g. virtual disk of 8G as compared
> to 4G in the current appliance.)

8G? Why not 64G? Or 200G? Am I missing something here? I always create
my VMs with *at least* 64Gb maximum HD space...

Also, why the need for a desktop system. You're building a *coda*
appliance, not a *linux* applicance, right?

>    7) Anything that might make this more useful to you that is not mentioned
> here?

Setting up network in the VM can be challenging. When moving the VM
from one machine to another, VirtualBox changes stuff in the virtual
NIC and the OS interprets that as a different NIC. That can change the
network interface from, for example, eth0 to eth1 and totally messes
up networking because you then have to edit /etc/network/interfaces
and restart networking.

I guess you could build a shell script to correct this but you gotta
do some testing...

Received on 2011-06-16 15:22:23