On Tue, Oct 16, 2001 at 12:05:11PM -0700, Zachary Denison wrote:
> Does coda work on 64 bit linux? such as redhat's ia64?

LWP and RVM are 'clean' as far as 64-bit is concerned. The biggest
problem is actually RPC2 because the '32-bit' RPC2_Integer was defined
as a long, and changing that causes massive all over the code. And every
cast needs to be examined because in many places assignments and
comparisons were 'forced' to get rid of compiler warnings, but these
casts are now often hiding potential breakage points on 64-bit platforms
as they surpress valuable compiler warnings.

> if yes, and I can theoretically get a linux server
> loaded with enough ram such as 10GB - 20GB which
> should not be a problem with 64bit addressing, so that
> I could then make a large RVM data partition, would I
> then be able to mirror the correspondingly size
> volume, in this case 200GB - 400GB ? (taking the rvm
> as 5% of the datastore) ?

Yeah, although I personally wouldn't want to wait for 200-400GB volume
to get loaded up during salvage.

Other solutions to the server scalability.

- RVM actually allows multiple segments that can be mapped, unmapped and
  remapped. The rvm memory allocator doesn't know how to handle this,
  but we could have a segment per volume and only have a subset of
  (recently used) RVM mapped at a time. This would allow us to run a
  server with 100GB of metadata even on a machine with a relatively
  small 'working set' as long as many volumes are relatively inactive.

  For this the RVM memory allocator needs to be taught about segments.
  And all memory pointers in RVM need to become relative offsets to
  allow mapping segments in arbitrary location (or pointers need to be
  'translated' after mapping a segment).

- Group a volume and it's clones (f.i. backup) together and have a
  simple server that can just export this volume. (Because of the tight
  integration, and COW, of a volume and it's backup the backup volume
  doesn't add that much overhead. Then have 100's of 'single-volume
  servers' running on a host. They could be managed by a central process
  that forks off volume servers on demand, i.e. as a result of a
  ViceGetVolumeInfo rpc2 request. And which keeps track of which port a
  volume server is listening to.

  Resolution and possibly reintegration could be handled by the same
  frontend to keep the volume servers as simple as possible. As far as
  clients are concerned we only need to add the portnumber information
  to volume location lookups.

Jan