Data Access Scheme for Beamtime Apr 2007

The following picture illustrates the data flow for the april 2007 beamtime.

This scheme on one hand provides access for all relevant tasks of data analysis on reasonable time-scales and on the other hand protects the crucial event-building and archiving task by forbidding direct data access to the event builder.

The data file size is reduced to a size of 0.5 GByte per file for better file handling

Data Pools

daq_netmem process receives subevents from the readout and inserts them to the corresponding buffers. The event builder (daq_evtbuild) reads the buffers and builds an event from the subevents. Then the data flow branches out to different data pools:

• Local disks
• Event Server (hadeb06) RAM disk. RAM disk has two directories:
  • /ramdisk/res (reduced hld files for Go4 online monitoring)
  • /ramdisk/copy (for Online DST production and exclusive access)

The size and amount of files on the Event Server RAM disk is controlled via special arguments of daq_evtbuild:

• --ressizelimit 80 (maximum number of files in /ramdisk/res)
• --secsizelimit 10000 (maximum size in MB of files in /ramdisk/copy)

Therefore these two directories on the RAM disk have the following limitations:

• /ramdisk/res = 2 GB maximum size
• /ramdisk/copy = 10 GB maximum size

TAPE-ARCHIVING: The protected data flow to the tape archive

• The Event Builder writes the files to its local disks.
• The archiver (HADES Archivist) reads periodically data from those data disk and archives them to the tape robot archives
• This is the only process which is allowed to read the data disks of the eventbuilder directly.
• The archivist periodically checks also /data/hadeb04/apr07 imported from hadeb04. If lxhadesdaq local disk (directory /data/lxhadesdaq/apr07) fails, the Event Builder should be restarted with a new path "-o /data/hadeb04/apr07". Then the data archiving will be continued from /data/hadeb04/apr07.

Go4/QA online monitor: reduced but fast data flow for online monitoring

• The Event Builder writes blockwise 1000 events into a small file to /ramdisk/res on a 12 GB RAM Disk on the Event Server (hadeb06) and then waits for 9000 events to write the next files, to get a reduced 1:10 data stream.
  • Those files have the same name as the large file written by the EventBuilder but extended by a continous number:
    • e.g. be06123040506.hld &larrow; be06123040506_X.hld
  • the Run Id in each of those small is identical to the run Id in the large file
• The QA File Server (lxg0447) retrieves via connect_res continously those small 2MB files to its local disk (/data.local2).
  • The process controlling the continous retrival runs on lxg0447 as user hades-qa and is described in the Howto Section under Start/Stop connect_res
  • This snapshort archive is exported as /misc/scratch2.lxg0447/qa/hld-snapshot-archive
  • a cron script /u/hades-qa/cron/clean_datalocal2.pl checks the snapshot archive two times a day and removes all files which are more than 1 day old if a total amount of files is larger than 500.

• Those small files are read by the Online Monitoring Software (Go4), analyzed and the QA plots are displayed on lxg0411.
  • The Go4 code uses a new HLD-Source of hydra looking for the latest files available (J.Markert)
• For the Online Monitor a direct access to the RAM-Disk is still provided, but will be switched off

exclusiv access for special authorized PCs:

• The Event Builder writes the same data files which are written to its disk to /ramdisk/copy (the RAM disk) on the Event Server.
• /ramdisk/copy has a size limit of 10 GB (about 20 hld files), i.e. about half of shift of data
• The oldest files are removed when a new file is written.
• In the upper counting house 5 PCs (2 GB RAM, 3 GHz HT, 2 x 160 GB internal hard disk, connected to Ethernet via marked cables) are set up for the different detector groups:
  • lxg0440 : RICH
  • lxg0441 : MDC
  • lxg0442 : START/VETO/TRIGGER
  • lxg0443 : TOF/TOFino
  • lxg0444 : Shower
  • lxg0451 : online DST production (lower counting house)
  • lxg0452 : online DST production (lower counting house)
• Only those 5 + 2 online PCs are allowed/able to access the data on the RAM disk of the Event Server via the script get_hld() provided by M.Traxler.
  • This script copies (avoiding NFS) the last closed file(s) from the RAM disk to the local disks of those PCs
• The groups are themself responsible to retrieve the data from the eventserver.
• The local disks on those PCs can be made visible/exported to selected users/groups/PCs so that low-priority tasks/users can access the data.
  • up to now visible are as /misc/scratch.lxg04xx or /misc/scratch2.lxg0XXX:
    • lxg0440: none
    • lxg0441: scratch.local and scratch.local2 (visible to lxg04* and lxi*)
    • lxg0442: none
    • lxg0443: scratch.local and scratch.local2 (visible to lxg04* and lxi*)
    • lxg0444: none
    • lxg0451: scratch.local and scratch.local2 (visible to lxg04* and lxi*)
    • lxg0452: scratch.local and scratch.local2 (visible to lxg04* and lxi*)
    • lxg0447: scratch.local and scratch.local2 (visible to lxg04* and lxi* and webserver)

Export of local disks of online DST pc's to a webserver is not granted any more.

DaqSniff -like connect-res

• The program connect-res provides for a stream like look access to a stream-like source
• see Howto section connect_res

NOTE
This scheme describes the access during run conditions. In case of real emergency access to the event builder can be granted, for sure. But these cases should be exceptions.

Status

• The PC's are ready
• get_hld script ready (M.Traxler)
• connect_res script ready (Radek)
• HADES Archivist running (S.Lang)
• RAM Disk QA - Replaced by connect_res script and QA File Server
• Event Server installed - running (M.Traxler)

Howto

• How to access the data

---

-- PeterZumbruch - 04 May 2006, -- SergeyYurevich - 09 Apr 2007

• data-access.ppt: PPT of data flow
  
• data-access.pdf: PDF of data flow