1. Some Ideas for a Revised Requirement List Dirk Duellmann

2. D. Duellmann Storage Manager Requirements –Volume - Address space sufficient for LHC data stores n at least 100PB total store size n assuming a maximum size of a single file of 10-100GB –Location Transparency - Heterogeneous and distributed access n transparent access independent I/O servers or client platform –need initial list of compiler platform combinations for clients & servers n no explicit host or filenames for readers –Navigation - Between arbitrary data objects n scalable performant access –e.g. lookup time depends less than linearly on the store size n inter-file and inter-host navigation –e.g. to support streaming of a single event into different physical files on multiple hosts. –Consistency & Robustness - Do we need Transactions? n Consistent concurrent updates to shared data n Support for crash recovery for db & application meta data

3. D. Duellmann Meta Data Requirements n Private Schema & Data - Users may change schema or catalogue of their private data without compromising the consistency of shared data n Scalable Meta Data - Database schema and catalogue implementation should not constrain concurrency or scalability n Schema Consistency - Enforce consistency between application classes, store schema and persistent objects –Ease extraction of data subsets for testing n We need more flexibility than any other typical ODBMS applications!

4. D. Duellmann Data Replication & Import/Export n Support for consistent replicas of subsets of data –to increase availability and performance n Which access control model ? n read-only - nobody writes after initial distribution –anybody may read, no locks required n ownership - only owner is allowed to write/update –remote readers may get stale (but consistent) data  random access - any process may write if it gets a lock –may require WAN locks on many machines n Which latency is acceptable for re-syncronisation? n after some high-level transaction –e.g. complete set of updates producing a new calibration, event collection, simulation run …  after each DB transaction –may require frequent WAN data access on many machines

5. D. Duellmann Language Binding Requirements n Language Support - at least for C++ and JAVA –Complete OO support including C++ templates and polymorphism (virtual functions) –Language interoperability (for a well defined subset of language constructs?)  Trade-off between  Risk for Experiment Code - Insulation against change of vendor  Transparency for End Users - As simple to use as transient data  Flexibility - More modern binding: e.g. activate/de-activate functionality  Performance - e.g. I/O on demand

6. D. Duellmann Language Binding Requirements n This system is overconstrained! –Multiple Solution exist for end-user interface –Standards Compliant Binding n ODMG binding - or at least ODMG like navigation model –direct use of binding & C++ pointers to persistent data (CMS) –Complete End-User Insulation n Experiment specific insulation layer - usually coupled to one specific application framework –complete conversion into transient objects (BaBar) –on demand conversion into transient objects using smart pointers (LHCb) n Should we split and define two Interfaces? –more flexible, performant, exposed lower level –more easy, customised, insulated higher level n Would a common insulation layer be possible/help at all? n Need to start a requirement definition group soon!