[OpenAFS-devel] Re: OpenAFS Master Repository branch, master, updated. openafs-devel-1_5_65-15-ge5cf14b

[Jeffrey Hutzelman]

--On Tuesday, October 06, 2009 11:41:35 AM -0400 Steven Jenkins=20
<steven.jenkins@gmail.com> wrote:

>>> - if you are =C2=A0making changes to ondisk formats, you must have the
>>> changes reviewed through afs3-standardization (we're already doing
>>> this -- I think)
>>
>> it's not an afs3-standardization issue, unless that format hits the =
wire.
>> what happens in my magic black box is none of your business otherwise,
>> for instance.
>
> I guess I misunderstood the situation: for example, I thought that if
> I propose a new on-disk format for the fileserver, that the discussion
> would need to go through afs3-standardization.
>
> Are you saying that a patch that modifies that format could get
> accepted without going through that discussion?

No, the discussion would certainly have to happen.  There may be=20
significant backward-compatibility issues, and there are plenty of casess=20
where the on-disk format used by OpenAFS's servers can be easily extended,=20
but only a limited number of times (e.g. when there are a limited number of =

spare fields), and we need to be sure each of those is important enough to=20
justify getting closer to a more difficult transition.  However, OpenAFS's=20
on-disk formats are generally not part of the protocol and thus are out of=20
scope for afs3-standardization.

One source of confusion here is that, at present, OpenAFS's on-disk=20
representation of directories is the same as that used to return directory=20
data in the results of RXAFS_FetchData.  Thus, a change to the directory=20
structure _does_ need to be discussed in afs3-standardization, or else=20
OpenAFS needs to be prepared to convert between its new on-disk=20
representation and the wire format.  However, this is a fairly unusual =
case.

-- Jeff