[OpenAFS] Longer volume names than 22 characters.

[Anders Magnusson]

Derrick Brashear wrote:
> On Tue, Feb 24, 2009 at 4:58 AM, Anders Magnusson <ragge@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