[OpenAFS] Longer volume names than 22 characters.

2009-02-24 Thread Anders Magnusson 
I took a quick look in the source code, and found that there are two 
interesting defines (in volser.h):


#define VOLSER_MAXVOLNAME 65
#define VOLSER_OLDMAXVOLNAME 32

So, obviously someone has thought about allowing longer names, but the 
checks seems to be against
the old name length so it don't work. 

What is needed if we want to use longer names?  And may it cause 
incompatibility with clients

or other cells or whatever?

-- Ragge
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Longer volume names than 22 characters.

2009-02-24 Thread Derrick Brashear 
On Tue, Feb 24, 2009 at 4:58 AM, Anders Magnusson ra...@ltu.se wrote:
 I took a quick look in the source code, and found that there are two
 interesting defines (in volser.h):

 #define VOLSER_MAXVOLNAME 65
 #define VOLSER_OLDMAXVOLNAME 32

 So, obviously someone has thought about allowing longer names, but the
 checks seems to be against
 the old name length so it don't work.
 What is needed if we want to use longer names?  And may it cause
 incompatibility with clients
 or other cells or whatever?

All vlserver calls already use 65:
const   VL_MAXNAMELEN   =   65;

Sadly, look what's on the on-disk volume header:
typedef struct VolumeDiskData {
struct versionStamp stamp;  /* Must be first field */
VolumeId id;/* Volume id--unique over all systems */
#define VNAMESIZE 32/* including 0 byte */
char name[VNAMESIZE];   /* Unofficial name for the volume */

So basically, you'd have to upgrade that, including having an upgrade
and downgrade path for volume headers (and then switch out vos
anywhere you wanted to actually be able to manipulate the volumes)

It's not actually all that hard, realistically.
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Longer volume names than 22 characters.

2009-02-24 Thread Anders Magnusson 
Derrick Brashear wrote:
 On Tue, Feb 24, 2009 at 4:58 AM, Anders Magnusson ra...@ltu.se wrote:
   
 I took a quick look in the source code, and found that there are two
 interesting defines (in volser.h):

 #define VOLSER_MAXVOLNAME 65
 #define VOLSER_OLDMAXVOLNAME 32

 So, obviously someone has thought about allowing longer names, but the
 checks seems to be against
 the old name length so it don't work.
 What is needed if we want to use longer names?  And may it cause
 incompatibility with clients
 or other cells or whatever?
 

 All vlserver calls already use 65:
 const   VL_MAXNAMELEN   =   65;
   
So that means that the protocol (what is sent between the client and server)
is already 65-byte-clean?

 Sadly, look what's on the on-disk volume header:
 typedef struct VolumeDiskData {
 struct versionStamp stamp;  /* Must be first field */
 VolumeId id;/* Volume id--unique over all systems */
 #define VNAMESIZE 32/* including 0 byte */
 char name[VNAMESIZE];   /* Unofficial name for the volume */
   
Hm, grepping shows that it is used in a bunch of structs.  But besides
VolumeDiskData ,
I assume all of them are only used inside the binaries...?

 So basically, you'd have to upgrade that, including having an upgrade
 and downgrade path for volume headers (and then switch out vos
 anywhere you wanted to actually be able to manipulate the volumes)
   
So what you mean is basically this:
- Change VNAMESIZE to 65
- Wrap VOLUMEINFOVERSION to 2
- Add compatibility code to where the struct is read from disk to
convert it to new internal format.
- Change all sanity checks for volume name length to new length.

 It's not actually all that hard, realistically.
   
Probably not if there's knowledge of the internals :-)  Biggest problem
for me would be that
I don't have any clues of the side effects of changes I might cause :-)

-- Ragge

___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info