Distributing Data around the BaBar collaboration’s Objectivity Federations

1. Distributing Data around the BaBar collaboration’s Objectivity Federations CHEP2000 Padova, February 7-11, 2000 Emanuele Leonardi - I.N.F.N. Roma Simon Patton - L.B.N.L. on behalf of the BaBar Data Distribution group

2. On-site DAQ: IR2Boot Prompt Reco: ProdBoot Analysis: AnalBoot Reprocessing: RecoBoot MC Production: SP2ProdBoot MC Analysis: SP2AnalBoot Off-site BaBar Regional Centers (CCIN2P3, INFN, RAL) copy (part of) AnalBoot and SP2AnalBoot MC Production Centers write data to SP2ProdBoot Objectivity Federations (FD) • How do we transfer data among these FD’s? • How do we ensure consistency in the data? E.Leonardi, S.Patton - CHEP2000

3. Data Transfer • A simple file transfer is not possible • FD must be “told” about the presence of new data • FD structure must be updated • Ad hoc tools (BdbDistTools) were developed • Based on BaBar database structure and organization • Assume total correspondence between FD’s DB Id’s (see later) • By-pass standard Objectivity DB administration tools • Only bulk data transfer for the moment E.Leonardi, S.Patton - CHEP2000

4. Data Export • Select data formats to export (AOD, ESD, …) • Check for modified/new DB files • Export these files (by-pass oocopydb: too slow) • Lock full DB • Copy file to stage-out area • Unlock DB • Get DB ID’s corresponding to exported files • Create TDF (Transfer Description File) with all info needed to re-attach the DB • DB file name, DB Id, Size, ... E.Leonardi, S.Patton - CHEP2000

5. Data Import • Copy all exported files (network or tape) to stage-in area • Use TDF to identify each file • Copy files to correct position in FD structure • Depends on local FD lay-out • Attach files to FD • ooattach makes a consistency check but it is VERY SLOW, so... • create empty DB file with correct name and position • ooattach the empty file (VERY FAST) • copy the real DB over the empty one E.Leonardi, S.Patton - CHEP2000

6. DBID Allocation • A “FD family” is a group of FD’s sharing part of the data • IR2Boot, ProdBoot, RecoBoot, AnalBoot, “off-site”-AnalBoot • Sp2ProdBoot, SP2AnalBoot, “off-site”-SP2 FD’s • To avoid overwriting of shared DB’s, each FD contains: • A “Global DB” area • all DB’s which may be shared with other FD’s in the same family • A “Local DB” area • all DB’s which are unique to that FD. • Each FD has write access to the Local area and to a preallocated portion of the Global area E.Leonardi, S.Patton - CHEP2000

7. DB Id’s allocation schema ProdBoot AnalBoot INFN-AnalBoot Local DB DB Id’s Part of Reco Data Reco Data ProdBoot Area Off-line Processing Global DB Production Skims AnalBoot Area Off-site User Processing User Skims INFN Area E.Leonardi, S.Patton - CHEP2000

8. Conclusions • Use of multiple Objectivity FD’s in different sites requires ad hoc tools to move data around. • Objectivity Administration tools are usually too slow: BaBar developed its own set of utilities to handle data distribution. These tools assume a complete correspondence between FD’s structures. • A careful management of DB Id’s is mandatory in order to avoid DB overwriting during data distribution. E.Leonardi, S.Patton - CHEP2000