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