On Wednesday, May 02, 2007 04:23:08 PM +0200 Hartmut Reuter
<[EMAIL PROTECTED]> wrote:
As I announced at the Hackathon-06 we are working on a combination of AFS
and object storage. This project was created in 2005. It was a
co-operation between Rainer Toebbicke from CERN, Andrei Maslennikov,
Ludovico Giammarino, and Roberto Belloni from CASPUR, and me from RZG.
The project has made good progress so that I would like to propose to put
the source now into the OpenAFS CVS tree.
Our source is based on the stable 1.4.4 release and can be found under
/afs/ipp-garching.mpg.de/.cs/openafs/openafs-1.4.4-osd. For all files we
changed we let the original version in place with a suffix ".orig".
There is also a doc-subdirectory with two pdf-files: one is a description
of what exists and the other one is a presentation I gave last week at
the Spring HEPIX 2007 meeting in Hamburg.
RZG is using this code already in production for normal AFS volumes, but
has enabled the use of object storage only for a few selected volumes.
The reason for not enabling object storage for all volumes is that we
don't want to make massive use of features in OpenAFS which have not yet
been approved by the OpenAFS commitees.
There is still missing a lot, but on the other hand it's time to start
beta-testing to find out all the nice bugs we have hidden under the
surface!
I suspect this is going to be way too big a change for 1.4.x. It might be
reasonable to integrate this into 1.5, but you really want to prepare
patches (using diff -ru) against the head. Patches are much easier to read
and review than is a modified source tree, and it is less likely that a
gatekeeper will screw up when applying your patch than that he will do so
when trying to manually port your changes, especially if they are large.
I'm sure I must have asked this during the hackathon, but does your work
require the use of new RPC numbers or new values for other protocol fields?
If so, you should send a request to [EMAIL PROTECTED] detailing what
you need new values for, so that appropriate values can be assigned. It's
actually best if you do this early, to avoid situations where different
people have used the same number for different purposes. This is
especially important because current OpenAFS source generally does not
reflect all of the numbers that have been assigned.
In general, submitting patches to OpenAFS is not the way to modify the AFS
wire protocol. Instead, protocol changes should first be brought up on the
afs3-standardization mailing list, which is the official forum for
discussing changes to the AFS protocols. Again, it is best to bring up
proposed changes before getting too far with the implementation, to limit
the amount of wasted effort if the mailing list has objections or
suggestions for improvement.
-- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
