Description of topic(s)

These topics describe the interaction of experiment software with local storage. They cover the I/O patterns of the software itself as well as the LAN protocols and filesystems used on top of the underlying hardware. Also we consider here the possible future evolution of storage technology, independent of WLCG activity and how that ought to influence the strategy adopted.

State of play and recomendations

See attached word document.

Comments

From Johannes (added by Wahid) Let me briefly summarize my view about the file streaming/direct access:

• For analysis the direct access to the input file is still the best option via dcap,file,root or nfs4.1 - if one does not read the full file, skipping through the file can save LAN bandwidth, CPU and processing time compared to the full file streaming - this can be seen in several ROOT work-flows, where only parts of the event or only certain events are read in - so the stage-in time of the full file is the largest overhead of the job. But more important in the view of 16/24/32/48 core machines, copying over the full input file(s) for analysis on the scratch disk will saturate the local node disk resources in capacity (so one has to add additional disks) or I/O (so one has to buy e.g. expensive SSDs). Reading directly from the mass storage system should also help in load balancing with hot replicas etc.
• For production jobs like G4 or Reco the demands are much more relaxed, since only a few files are being processed and the jobs are limited by the CPU - so full file streaming to the local scratch disk is a useful option.

-- WahidBhimji - 15-Feb-2012