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

[Derrick Brashear]

moving to openafs-devel, which has non-overlapping membership, but is
more appropriate.
ther cells or whatever?
>>>
>>
>> All vlserver calls already use 65:
>> const =A0 VL_MAXNAMELEN =A0 =3D =A0 =A0 =A0 65;
>>
> So that means that the protocol (what is sent between the client and serv=
er)
> is already "65-byte-clean"?

yes.

>> Sadly, look what's on the on-disk volume header:
>> typedef struct VolumeDiskData {
>> =A0 =A0 struct versionStamp stamp; =A0/* Must be first field */
>> =A0 =A0 VolumeId id; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Volume id--unique=
 over all systems */
>> #define VNAMESIZE 32 =A0 =A0 =A0 =A0 =A0 =A0/* including 0 byte */
>> =A0 =A0 char name[VNAMESIZE]; =A0 =A0 =A0 /* Unofficial name for the vol=
ume */
>>
> Hm, grepping shows that it is used in a bunch of structs. =A0But 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.

yes. well, basically. but one more thing. you'd want a tool not unlike
what cnvldb is for vlserver databases, to be able to convert the
volume header back to the old format.

and if you're going to do this, we'd want to make other changes to the
volume header format at the same time, so we don't end up needing to
do this again in 3-6 months.

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

this would actually not be an unreasonable google summer of code
project; a design document could be gathered first which described the
new volume header format; the basic implementation could be done
inside a week, and once that was done, the student could spend a
decent amount of time getting the backout tool correct.