Andy, Booker and Wei had a meeting today about the two options to 
transfer data in and out of a xrootd cluster. We all agree that gsiftp 
is the way to go.

1) A gsiftp gateway is potentially much simpler to implement comparing 
to a SRM. It may still involve some hard work though.

2) Gsiftp interacts better with glite FTS. Neither FTS and SRM are quite 
mature.

3) A gsiftp gateway solution will allow all xrootd nodes to remain 
within IFZ.

4) We can work about SRM interface later, should it ever become necessary.

The disadvantage of a gateway solution is the potential point of failure 
/bottleneck. If the goal is to transfer 1TB/day (or 100Mbit/sec), the 
gateway will likely not a bottleneck.

Booker will look at the implementation. I attached a note from Booker 
before the meeting.


Wei Yang  |  [log in to unmask]  |  650-926-3338(O)



Stephen J. Gowdy wrote:
> ATLAS SCCS Planning 10Jan2007
> -----------------------------

> 3. HPSS/gsiftp/xrootd
> 
>    Want to allow xrootd to be used locally (and eventually over the
>    WAN) for data access while also fitting in the ATLAS model for data
>    import and export.
> 
>    Booker should talk to AndyH about what is needed to help make this
>    happen. There is a pluggable system of deciding what backend store
>    you want to use for SRM, might be a way forward. Need to understand
>    how easy/hard that is to do. This would be a stop-gap measure and
>    not a complete solution.
> 
>    Another option is that there is a plug-in module for gsiftp to talk
>    to the backend storage. It is available for Unix file system, HPSS
>    and some other systems but not xrootd. xrootd has a posix interface
>    so perhaps we can make it talk to xrootd via the unix file
>    system.
> 
>    There should be a meeting, hopefully tomorrow afternoon, to talk
>    about this to see what would work. Will draft options at the
>    meeting for circulation.