Hi Horst,

Before I get into this.... Wilko and Fabrizio, please respond to the areas 
indicated below.

> 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?
It depends on what you are trying to accomplish. In general, xrootd follows 
the human-like philosophy that if no one is interested in a file then it 
doesn't want to know about it either. That allows it to scale quite well 
while maintaining a very small memory footprint.

Now, if a set of files is expected to be used, you can provide the server 
with that list through the administrative interface (see below). Typically, 
an application program does this ahead of access and the system will try to 
make sure that it has enough information to speed subsequent access.

> Provide a filelist to the redirector? How?
See the XrdClientAdmin Class, Prepare(). This is also available in Java and 
Perl. Wilko Kroeger can give you full details.

> Make open/close calls for each new file just written?
The preferred method is using Prepare(). However, please be aware that in 
general, the really best mechanism is to allow applications to simply open 
files as they need them unless you are absolutely certain that you *know* 
all of the files that will be opened in the next, say, eight hours. 
However, as you found out that in the current production release, the client 
is delayed a fixed amount of time in order for all the information to be in 
place prior to letting the client access to the file. In some sites, such as 
yours, this has proven to be very awkward. The three ways around this are a) 
using the Prepare() mechanism, b) using asynchronous open at the application 
level (Frabrizio Furano can give you details on this), or c) installing the 
development version (which will soon become the production version after 
test certification). The newest version does no introduce a significant 
delay (typically less than 200 microseconds) in the common cases when 
opening an unknown file. So, one-off application-level opens should still 
remain the preferred mechanism. The prepare mechanism will remain the 
preferred method to "stage" in multiple files.

> Tell the redirector to rebuild his cache tables? How?
You definitely do not want to do this. In fact, please do not do this; 
xrootd has no notion of  "rebuilding tables". That's not the architectural 
philosophy it employs. To force it do so would grind the system, for that 
matter, any system that has to deal with millions of files and thousands of 
simultaneous clients, to a standstill.

> 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.
You can tune this via config file using the "olb.delay lookup" directive. I 
have seen people tune this down to 1 second (the specifiable minimum) and be 
relatively happy with it. That said, the latest development version that is 
currently available eliminates the delay altogether. In the mean time, you 
can use the prepare mechanism for the files of interest. Of course, it can 
be abused. If you decide to prepare all possible files, the main scaling 
mechanism used by xrootd will have been violated and you will get a poorly 
performing system. Additionally, it will not help you beyond the memory 
window that xrootd employs in order to scale itself in the presence of 
millions of files. In other words, xrootd does not have a permanent memory, 
the only thing allows it to not only withstand violent dynamic changes in 
the configuration but to accommodate them in real-time.