[OpenAFS-devel] AFS + Object Storage

Hartmut Reuter reuter@rzg.mpg.de
Tue, 08 May 2007 10:18:59 +0200


Jeffrey Hutzelman wrote:
> On Wednesday, May 02, 2007 04:23:08 PM +0200 Hartmut Reuter 
> <reuter@rzg.mpg.de> 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.

Of course, you are right that this change will not go into 1.4.x, but to 
have a stable reference and a base which can immediately be used in 
production I always put my changes into the current stable release.

Of course the changes are large. If the gate-keepers prefer I could 
create a version based on another CVS branch. But it takes a while (it's 
a manual port, anyway) and I must be sure this branch doesn't change too 
much in the meantime.

Which one would you suggest?

> 
> 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 registrar@central.org 
> 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.

I let a gap in the RPC numbers, but now I also have sent a request to 
registrar@central.org. If I would have to change the RPC numbers again 
it wouldn't be a drama. We are using my code base in production, but the 
new features aren't activated for normal AFS volumes and on normal AFS 
clients.

> 
> 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.

That was the reason why I came to the Hackathon last year to inform the 
AFS developers early about our project.

Hartmut

> 
> 
> -- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
>   Sr. Research Systems Programmer
>   School of Computer Science - Research Computing Facility
>   Carnegie Mellon University - Pittsburgh, PA
> 


-- 
-----------------------------------------------------------------
Hartmut Reuter                           e-mail reuter@rzg.mpg.de
					   phone +49-89-3299-1328
RZG (Rechenzentrum Garching)               fax   +49-89-3299-1301
Computing Center of the Max-Planck-Gesellschaft (MPG) and the
Institut fuer Plasmaphysik (IPP)
-----------------------------------------------------------------