XROOTD-L Archives

Support use of xrootd by HEP experiments

XROOTD-L@LISTSERV.SLAC.STANFORD.EDU

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Goeringer Dr. Horst" <[log in to unmask]>
Date:
8 Mar 2006 17:24:44 +0100Wed, 8 Mar 2006 17:24:44 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (42 lines)
Hi all,

at GSI in Darmstadt/Germany, the home of large heavy ion experiments
and Alice tier 2 center,
we offer some ten file servers as file cache for batch farm analysis.
These file servers are filled and managed by gStore, 
the GSI Mass Storage System.

In preparation of a batch farm analysis each authorized user is able 
to fill any amount of the available cache with files from our tape
libraries
just submitting a single gStore command. gStore takes care for proper 
distribution of the new files among the file server nodes.
During analysis the jobs in the batch farm read their input files from
cache
very efficiently with gStore commands or via the RFIO API.
So - sorry for the long poetry, but I think though this is a very common
scheme
it was necessary as background to understand our problem.

For the future we plan to provide xrootd as additional access method 
from the batch farm (read single files). 
First test installations of xrootd servers and redirector are done.

Now my question: What is the most efficient way to tell the redirector
that there are new files (100s or 1000s) on "his" file server disks?
Provide a filelist to the redirector? How?
Make open/close calls for each new file just written?
Tell the redirector to rebuild his cache tables? How?
It is very important that the redirector knows all files
before an analysis run starts, as the 5 seconds latency time to find
a new file is not acceptable.

Thank you very much for your help!
Horst Goeringer







ATOM RSS1 RSS2