--On Tuesday, October 06, 2009 11:41:35 AM -0400 Steven Jenkins
<[email protected]> wrote:
- if you are making 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
significant backward-compatibility issues, and there are plenty of casess
where the on-disk format used by OpenAFS's servers can be easily extended,
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
justify getting closer to a more difficult transition. However, OpenAFS's
on-disk formats are generally not part of the protocol and thus are out of
scope for afs3-standardization.
One source of confusion here is that, at present, OpenAFS's on-disk
representation of directories is the same as that used to return directory
data in the results of RXAFS_FetchData. Thus, a change to the directory
structure _does_ need to be discussed in afs3-standardization, or else
OpenAFS needs to be prepared to convert between its new on-disk
representation and the wire format. However, this is a fairly unusual case.
-- Jeff
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
