Well, at least one person read this: he pointed out that I forgot to
finish one part. Add also Igor to the Cc in case he wants to add anything....
On Tue, Sep 07, 2004 at 10:55:20PM +0200, Peter Elmer wrote:
> > Recovery use cases:
> > -------------------
> >
> > Admin should be able to close file descriptor selectively or all of it.
> > ===> Used for substituting files on disk, like during conditions sweeps.
>
> This we've not yet dealt with. Since we (currently) only serve event data
> via xrootd, we have yet to deal with any "version" issues like this for files.
> As you probably know, I'm ever more of the opinion that BaBar
...should provide access to conditions for the vast majority of jobs as
simple files (and in particular use ROOT I/O). This would have the effect
of making the conditions data access/distribution/management a blip on top
of that of the event data. Only in the tiny corner of phase space, where
updates actually need to happen, would we use something like MySQL. In BaBar
we have done something sane and the places where conditions are updated
are localized at SLAC (the online system, the "master" and the data prompt
calibration farm). Thus my preferred solution for the conditions is to use
MySQL in those places and have an "export" version in simple files using
ROOT I/O for the rest of the world (99.99% of the access).
Coming back to Artem's point above about "substituting" new versions of
files (i.e. where the "version" was effectively implicit), I think that was
one of the most error-prone and confusing parts of the objectivity data
distribution/management. It may be unavoidable in the interactions between
the MySQL portions of the conditions (I don't know how that will work), but
in any flat-file or ROOT I/O based "export" version of the conditions we should
avoid repeating that mistake. Files should be given explicit version numbers
(i.e. in their names) to replace earlier versions.
Bottom line: for BaBar at least, replacing files on disk with new versions
of themselves is not, and will not be, needed and hence no specific support
should be needed from xrootd. (And AFAIK no support for what Artem requested
exists in xrootd beyond the normal closing of the files and interactions with
the underlying filesystem WRT open files, but Andy may correct me....)
Pete
-------------------------------------------------------------------------
Peter Elmer E-mail: [log in to unmask] Phone: +41 (22) 767-4644
Address: CERN Division PPE, Bat. 32 2C-14, CH-1211 Geneva 23, Switzerland
-------------------------------------------------------------------------
