On Fri, Aug 19, 2016 at 03:25:30PM -0400, Jan Harkes wrote:
> On Fri, Aug 19, 2016 at 04:51:01PM +0200, u-x417_at_aetey.se wrote:
> > Apparently there was at least one inconsistency in int vs long
> > in rdsinit (using an int value as a counter to detect the
> > end of the zero initialization run), but it was trivial to fix.
> 
> PRs are welcome, or even pointing out where. If I had to guess, I think
> it is 'int remaining_space;' in rds_init.c:rds_init_heap().

sed -i.orig '
/int err, fd, i;/c\
    int err, fd;\
    long i; /* i is going to be compared to a long */
' rds/rdsinit.c

The use of i (as a counter in zeroing) is near the end of rds/rdsinit.c

> It was written to work on 64-bit systems and even to allow it to manage
> 64-bits of space on a 32-bit system, but in that case you'd have to
> page segments in and out of the available address space. Not sure how
> much of this was tested.
> 
> I know we ran on ILP64 (DEC Alpha) in the past as well as sparc64 linux
> at some point. But I am not sure how well tested RVM is on LP64. My

Most probably it was below 2G at that time. (IIRC sparc64 is LP64)

x86_64 LP64 Coda clients do well, so I think LP64-rvm can be considered
reasonably well tested at this time, for "31-bit" RVM sizes.

> servers are all still running 32-bit binaries because there are
> incompatibilities between 32-bit and 64-bit Coda servers in areas like
> resolution so upgrading to 64-bit cannot be done incrementally.

We run 32-bit servers too but would consider switching to 64-bit if this
would help to increase RVM size.

> > This clearly indicates that the code was never used on LP64 platforms
> > with RVM > 2GB. Nevertheless just to be sure I would like to ask
> > on the list, whether RVM was tested or used on ILP64 platforms (Alpha?)
> > with sizes exceeding 2G?
> > 
> > On the other hand, may be there was never an intention to support RVM
> > bigger than 2^32 and a rewrite or replacement is needed to do such
> > a thing? Hope the authors can tell.
> 
> Not sure where the original authors are, but it could be that it was
> designed to handle only 32-bit (31-bit, if signed?) sized segments
> in a 64-bit address space. A Coda server only uses a single segment,
> which therefore would be limited to either 2 or 4GB. But this is just a
> guess without looking at the code.

My reading of the code was very shallow but it looked to me like
an interface to data with sizes up to 2^(sizeof(long)-1).

I guess a 64-bit Coda server could potentially be able to use a segment
bigger than 4G, but I did not look at that part of the code.

> RVM actually consists of 3 parts, there is the transaction log which can
> track and recover modifications to files, then there is a segment mapper
> which can map all or parts of these files into the process address space.
> Finally there is the rds allocator which acts like a recoverable heap,
> most likely your issue is isolated to just that last part.

Apparently and unexpectedly, thorough checking and at least some fixing
is needed in librvm to be able to use 64-bit segments; probably
corresponding checks and adjustments are needed in the server too.
This is more work than I hoped but in any case good to know.

Thanks for the explanations Jan.

Best regards,
Rune