Clearcase (was Re: [ILUG] Seeking Alternatives )

[Justin Mason]

David Neary said:

> >  Would it not be more accurate to say that multi-site development was
> > beaten into Clearcase ? I got the impression that it was a hacked NFS
> > server, that had loads of permissions/transparent revisions built in. NFS
> > was never designed to be anything bar local..
> 
> I don't think so.... ClearCase's multi-site is based on a kind of mirror
> system - you havbe your main code in one place, and everywhere else uses
> a mirror copy of this code. The local changes are synced regularly
> throughout all the copies worldwide. The NFS system is only used (by us)
> for cases when you want to compile something on a system that doesn't
> support clearcase natively. That implies local to me... you would just
> use a local viewserver to set a view into the source (equivalent to
> doing a read-only checkout from CVS), and then NFS export the resulting
> filesystem to your strange local system.

Partly true -- the MultiSite functionality is not NFS-based.  However,
Clearcase in local operation is entirely NFS-based.

Multisite: Clearcase itself is based around NFS, loading files via NFS
from the VOB server. MultiSite is a mirroring system that mirrors the VOB
server to satellite servers that may be miles away (in net terms). They
can then operate as entirely separate Clearcase networks until the next
scheduled sync-up time.

To expand on the local case, where you're running a view server locally:
the processes accessing the view's filesystem (cc, make, ls, etc.) call
into the MVFS (clearcase' multi-version filesystem) handler in the kernel,
which does some magic of some sort and calls out to a view_server process
running on the local machine. 

It then decides whether it can satisfy the request with either a view
private file, loaded from the local filesystem, or whether it should hand
off to the VOB server as an NFS request.

In fact I think the view_server process may optimise this by getting the
MVFS kernel module to do the NFS request if the file has not been checked
out.

so the chains are:

view private file:

  cc -> MVFS (in kernel) -> local filesystem (and back again)

shared, non-checked-out VOB file (most frequent case in compiles):

  cc -> MVFS (in kernel) -> NFS to VOB server -> filesystem on VOB machine

The "nfs" case is where you don't have Clearcase installed on the target
machine. That's *really* slow:

  cc -> NFS to view machine -> MVFS (in kernel) -> local filesystem (and
  back again)

or for unchecked-out files:

  cc -> NFS to view machine -> MVFS (in kernel) -> NFS to VOB server ->
  filesystem on VOB machine

(note the doubled NFS traffic!)

Because every file request goes through the MVFS module (which is not as
fast as 100% local filesystem disk accesses), and because maybe 90% of
your file accesses are not for checked-out files and are not view-private
files, a lot of NFS happens. As a result the VOB server has to be a very
beefy NFS server, since you can only have 1 VOB server unless you pay the
megabucks for a MultiSite license.

That's why it's slower than other non-NFS-based systems,

--j.