[AFS3-std] RxOSD claim on 2 structure members

[Derrick Brashear]

On Fri, Jun 12, 2009 at 9:50 AM, David Boyes<dboyes@sinenomine.net> wrote:
>> However, the future isn't the issue -
>> it's the
>> > past we have to contend with. For many years, there has been a free
>> for all
>> > on the unused fields and bits in the AFS protocol. This means that
>> any use
>> > of them has to be carefully considered. I suspect that our only way
>> forwards
>> > is going to be to (as David H. suggests) revise the protocol, and
>> then make
>> > very clear that unused fields are not 'spare', but 'reserved'.
>
> I think that was me, but nevertheless, seems like the right thing to me. =
If you want to control the use of the fields, I think it's the only way to =
clearly make the statement that use of these fields outside the registered =
process is a at-your-own-risk process.
>
>> In the event some "on-disk structure" has been conflated into this
>> discussion, which it seems to have,
>> I feel I should mention that uses of those could easily be injected as
>> tickets in RT, which would help
>> make changes that use those fields upstream (as opposed to private
>> code forks) able to detect alternate use
>> and avoid potential data loss and corruption.
>
> Suitable. It would be helpful to have something like the RFC1000 assigned=
 numbers list of assigned uses every so often so that someone doesn't have =
to sort through the RT noise every time some change is contemplated, though=
.
>
>> Of course, such changes would be out of scope for a discussion of
>> RPCs, and would in fact be
>> implementation-specific and so out of scope for this list entirely.
>
> So you are saying that the effective freeze on revs to the on-disk format=
 is lifted?

I'm unsure of what freeze is in question.

1) any site can do whatever it wants with its disks, and always could
since 10/2000.
2) what openafs ships, and how hard it works to accomodate people who
used nominally unused, is a topic for openafs-devel, rather than than
here, since it has zilch to do with standardizing what's on the wire.
that Dan Hyde could point to RT illustrates why I shared the disk
format point here, but that ticket being mentioned here doesn't help
(nor hinder) the institutional memory of who's using what.

(that said:
2a) realistically, if XYZ enhancement which can ship today needs a
field a third party has used for something which can never be merged
or is not ready to merge, it would be easier to accomodate, or at
least warn, other users, if RT knows what's going on.

2b) in the case for prior (Transarc) on-disk version updates, a
downgrade tool was provided. as long as the downgrade tool is
bulletproofed, disk format upgrades for things which are not ubik
databases (and thus copies around between servers which may be of
divergent versions in real time) are hard only in "the administrator
and if there's a long outage involved, the users, eventually want to
shoot the developers, so ideally, get it right the first time".
further, at a point where OpenAFS demand attach fileservice is stable
enough to become the default, unlike now, if the upgrade can be done
in the fileserver during preparation to attach, the impact of this can
be much lower, as long as all volumes are not demanded at once.
)

> We can take this offlist if you prefer.
>
> --d b
>



--=20
Derrick