[OpenAFS] Current "balance" practice?

[Jonathan Proulx]

Hi All,

We're currently running a sightly hacked up version of balance-1.1a (I
belvieve originally from ftp://ftp.andrew.cmu.edu/pub/AFS-Tools/ ) on
a old 32bit linux server ( well 32bit kernel and userland hardware
under it is 64bit ) with openafs 1.6.1

Shockingly this seesm to still work, but I'm trying kill off the
oldest straggling servers and neither copying the binary (and using
32bit libs ) nor recompiling it seems to work on new 64bit OS with
openafs 1.8.2

I've also noticed that the Wiki points to an abandoned perl
implementation from 2007
( https://www.eyrie.org/~eagle/software/afs-balance/ )

Are people using that now?

Anyone ported the original balance forward to the modern age?

Other options I've not seem?

Thanks,
-Jon

--

[Jeffrey Altman]

Post by Jonathan Proulx
Hi All,
We're currently running a sightly hacked up version of balance-1.1a (I
belvieve originally from ftp://ftp.andrew.cmu.edu/pub/AFS-Tools/ ) on
a old 32bit linux server ( well 32bit kernel and userland hardware
under it is 64bit ) with openafs 1.6.1
Shockingly this seesm to still work, but I'm trying kill off the
oldest straggling servers and neither copying the binary (and using
32bit libs ) nor recompiling it seems to work on new 64bit OS with
openafs 1.8.2

The "balance" sources date back to IBM 3.4 or earlier and relies upon
ubik_Call() instead of

ubik_VL_SetLock()
ubik_VL_ReleaseLock()

ubik_Call() is no longer used internally by OpenAFS but it is still
exported. ubik_Call() relies upon varargs that are unlikely to
interpret parameter types properly on systems with 64-bit pointers
and/or size_t.

Unless there are other 64-bit safety issues within balance itself,
switching to ubik_VL_SetLock() and ubik_VL_ReleaseLock() might be
sufficient.

Post by Jonathan Proulx
I've also noticed that the Wiki points to an abandoned perl
implementation from 2007
( https://www.eyrie.org/~eagle/software/afs-balance/ )

Although similarly named Russ Allbery's balance which was developed at
Stanford is unrelated to Dan Lovinger's balance. Russ' balance can make
decisions based upon volume count and volume size whereas Dan's can make
decisions based upon weekly volume usage as well.


Jeffrey Altman

[Chaskiel Grundman]

Post by Jeffrey Altman
ubik_VL_SetLock()
ubik_VL_ReleaseLock()
ubik_Call() is no longer used internally by OpenAFS but it is still
exported. ubik_Call() relies upon varargs that are unlikely to
interpret parameter types properly on systems with 64-bit pointers
and/or size_t.

I'll probably be looking at upgrading balance for our own internal use in
the next month or two, but another ftp.andrew.cmu.edu release is probably
not in the cards (especially since something else I'm doing in the next
few months is retiring ftp.andrew.cmu.edu). Perhaps I'll put it on github.

There is another problem beyond 64-bit safety. It appears that the some of
the openafs devs didn't learn from the project's own experience with the
linux developers, as

extern afs_int32 vsu_ClientInit(int noAuthFlag, const char *confDir,
char *cellName, afs_int32 sauth,
struct ubik_client **uclientp,
int (*secproc)(struct rx_securityClass *,
afs_int32));


in <= 1.6 has become

extern afs_int32 vsu_ClientInit(const char *confDir, char *cellName,
int secFlags,
int (*secproc)(struct rx_securityClass *,
afs_int32),
struct ubik_client **uclientp);


in 1.8. and I can't even use #ifdef VS2SC_NEVER to detect the change --
it's an enum.

[Jeffrey Altman]

Post by Chaskiel Grundman
There is another problem beyond 64-bit safety. It appears that the some of
the openafs devs didn't learn from the project's own experience with the
linux developers, as
extern afs_int32 vsu_ClientInit(int noAuthFlag, const char *confDir,
char *cellName, afs_int32 sauth,
struct ubik_client **uclientp,
int (*secproc)(struct rx_securityClass *,
afs_int32));
in <= 1.6 has become
extern afs_int32 vsu_ClientInit(const char *confDir, char *cellName,
int secFlags,
int (*secproc)(struct rx_securityClass *,
afs_int32),
struct ubik_client **uclientp);
in 1.8. and I can't even use #ifdef VS2SC_NEVER to detect the change --
it's an enum.

That would be AuriStor's fault. The change in question was

commit 3720f6b646857cca523659519f6fd4441e41dc7a
Author: Simon Wilkinson <***@your-file-system.com>
Date: Sun Oct 23 16:21:52 2011 +0100

Rework the ugen_* interface

The vsu_ClientInit() signature change was a side-effect of the
refactoring of ugen_ClientInit(). No one remembered the possible out of
tree usage of vsu_ClientInit(). vsu_ClientInit() is not an exported
function. As such its status as public is murky at best.

I suggest using the existence of one of these CPP macros as a test.
They were added shortly after the vsu_ClientInit() signature change was
merged.

/* Values for the UV_ReleaseVolume flags parameters */
#define REL_COMPLETE 0x000001 /* force a complete release */
#define REL_FULLDUMPS 0x000002 /* force full dumps */
#define REL_STAYUP 0x000004 /* dump to clones to avoid offline
time */

The introduction of enum vol_s2s_crypt came much later.

If you would prefer AuriStor can submit a change to restore the prior
signature.

Jeffrey Altman

[Benjamin Kaduk]

Post by Jeffrey Altman

Post by Chaskiel Grundman
There is another problem beyond 64-bit safety. It appears that the some of
the openafs devs didn't learn from the project's own experience with the
linux developers, as
extern afs_int32 vsu_ClientInit(int noAuthFlag, const char *confDir,
char *cellName, afs_int32 sauth,
struct ubik_client **uclientp,
int (*secproc)(struct rx_securityClass *,
afs_int32));
in <= 1.6 has become
extern afs_int32 vsu_ClientInit(const char *confDir, char *cellName,
int secFlags,
int (*secproc)(struct rx_securityClass *,
afs_int32),
struct ubik_client **uclientp);
in 1.8. and I can't even use #ifdef VS2SC_NEVER to detect the change --
it's an enum.

That would be AuriStor's fault. The change in question was
commit 3720f6b646857cca523659519f6fd4441e41dc7a
Date: Sun Oct 23 16:21:52 2011 +0100
Rework the ugen_* interface
The vsu_ClientInit() signature change was a side-effect of the
refactoring of ugen_ClientInit(). No one remembered the possible out of
tree usage of vsu_ClientInit(). vsu_ClientInit() is not an exported
function. As such its status as public is murky at best.

Indeed, I use the export symbol lists for the public shared libraries to
determine what standard of review to apply to API changes, and non-exported
symbols mostly get a free-for-all for API changes.

Post by Jeffrey Altman
I suggest using the existence of one of these CPP macros as a test.
They were added shortly after the vsu_ClientInit() signature change was
merged.
/* Values for the UV_ReleaseVolume flags parameters */
#define REL_COMPLETE 0x000001 /* force a complete release */
#define REL_FULLDUMPS 0x000002 /* force full dumps */
#define REL_STAYUP 0x000004 /* dump to clones to avoid offline
time */
The introduction of enum vol_s2s_crypt came much later.
If you would prefer AuriStor can submit a change to restore the prior
signature.

That said, I do not subscribe to the philosophy of "aggressively break APIs
not documented as stable", and would likely merge such a change if there
was demand for it. (But I leave it to Chaskiel et al to express such a
demand, if one is indeed present.)

-Ben

[Chaskiel Grundman]

Post by Benjamin Kaduk

Post by Jeffrey Altman
The vsu_ClientInit() signature change was a side-effect of the
refactoring of ugen_ClientInit(). No one remembered the possible out of
tree usage of vsu_ClientInit(). vsu_ClientInit() is not an exported
function. As such its status as public is murky at best.

Indeed, I use the export symbol lists for the public shared libraries to
determine what standard of review to apply to API changes, and non-exported
symbols mostly get a free-for-all for API changes.

If that's how the world works, then commit to it, and don't publish the related archive libraries or headers anymore. I guess this is already in progress, as the prototypes for UV_* functions used by balance and backup clients (in volser_prototypes.h and volser_internal.h) are not part of distributions.

The "public" shared libraries started life as "what the threaded fileserver and windows processes running in the service manager need from rx/rxkad/des/comerr" and "what the threaded fileserver needed from afsconf" + "what libadmin needed from the kaserver client". Only people who really cared about getting rid of LWP would have tried to migrate to them from the old archive libraries._______________________________________________
OpenAFS-info mailing list
OpenAFS-***@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

[Benjamin Kaduk]

Post by Chaskiel Grundman

Post by Benjamin Kaduk

Post by Jeffrey Altman
The vsu_ClientInit() signature change was a side-effect of the
refactoring of ugen_ClientInit(). No one remembered the possible out of
tree usage of vsu_ClientInit(). vsu_ClientInit() is not an exported
function. As such its status as public is murky at best.

Indeed, I use the export symbol lists for the public shared libraries to
determine what standard of review to apply to API changes, and non-exported
symbols mostly get a free-for-all for API changes.

If that's how the world works, then commit to it, and don't publish the related archive libraries or headers anymore. I guess this is already in progress, as the prototypes for UV_* functions used by balance and backup clients (in volser_prototypes.h and volser_internal.h) are not part of distributions.

It's definitely something to think about for 2.0, yes.

Post by Chaskiel Grundman
The "public" shared libraries started life as "what the threaded fileserver and windows processes running in the service manager need from rx/rxkad/des/comerr" and "what the threaded fileserver needed from afsconf" + "what libadmin needed from the kaserver client". Only people who really cared about getting rid of LWP would have tried to migrate to them from the old archive libraries.

Fair points all.

Thanks,

Ben