Fatto lo stato di tutte le varie istanze disponibili.

 dCache: sembra esserci un problema con CHIMERA che impedisce sistematicamente di avere piu' di "n<10" processi paralleli. Giacinto riporta che e' in contatto con uno degli sviluppatori CORE di dCache a DESY (Tigran Mkrtchyan) per avere conferma che la versione unofficially released fissi il problema. Giacinto e' altresi' riluttante a fare un downgrade al vecchio PNFS visto che in futuuro (allorche' tutti si muoveranno a 1.8 e un tool di migrazione a CHIEMRA sara' approntato) questo sara' il sistema di default e non pfns. Durante il meeting Giacinto riceve informazione da Tigran che in un paio di ore ricevra' la versione che sicuramente fissa il problema riscontrato e quindi Elisa gia' a partire dal pomeriggio potrebbe procederre nei tests. [*]

StoRM: non ci sono errori ma e' lento. Luca e Riccardo spiegano che il BE non ha ancora la feature di auto-pulizia del MySQL quindi questa lentezza e' imputabile a un DB pieno di richieste vecchie di 4 mesi. Gli Stormers proveranno l'11/10 (di ritorno dalla missione a Ginevra) a pulire il DB e ricrreare indici cosi' che Elisa potra' ricominciare. (per inciso lentezza riportata anche al GSSD da Atlas). Chiesti chiarimenti inoltre su quanto riportato da Atlas riguardo fallimenti nel ciclo put quando la quota settata si approssima. Spiegato che il ptp alloca dinamicamente blocchi di memoria e questi possono benisssimo andare oltre la quota settata (1TB dato ad Atlas) ma che in questo caso lo stat successivo ritorna una struttura non gestibile dal BE che si incasina. (per inciso anche il removal fallisce per la stessa ragione).Work in progress. Anche da capire come pubblicarsi in produzione. Per il proseguiemento dei tests e' stato inoltre menzionato che il gridftp (attualmente nel BE) verra' spostato in uno dei disk servers per alleggerirlo.

CASTOR: Elisa riporta gli ultimi giorni di attivita' c ontro CASTOR al CERN e il problema osservato del ciclo put. La cosa importante e' che via GSSD ha scalato i findings a Lopresti/Shaun che hanno seguito con molto interesse il test in progress reclamando anche il fatto che stress tests non sono fatti su CASTOR.. Il problema era che il BE perdeva la richiesta mandata al LSF. Elisa conferma che il problema (causando un 3% di failures a macchina non stressata) e' stato curato completamente con l'ultima patch e anche le performances sono migliorate di un fattore 3. I CASTORers sono contenti di questo. Al CERN 1 sola macchina per BE/FE come al CNAF. Richiesto se fosse possibile allineare l'architettura con quella delle altre istanze sotto test. Sembra molto piu' feasible allineare le altre a CASTOR (downgrade) per difficolta' tecniche da capire meglio.

 Il software di CASTOR al CNAF deve comunque essere mantenuto quanto piu' possibile allineata con la versione del CERN. Forse varrebbe la pena applicare direttamente la patch che si avra' al CERN il 15 che fissa alcuni altri problemi circa l'uso di CASTOR come pure disk. Vara' la pena riconfrontare dopo l'update del 15 le prestazioni come variano. Luca Dell'Agnello e Lopresti dovrebbero fornire dei piani sul CNAF. 

DPM:Roberto riporta di come sia "scomodo" includere DPM nei tests dopo le ultime vicende al CERN. Questo a meno che non si ridefiniscano gli obbiettivi di questa attivita' che sono tutt'ora volti a verificare (almeno da come e' stata presentata agli esterni) se e come le varie soluzioni di Storage in WLCG possono soddisfare lo use case di un T1 service per un esperimento di HEP quale LHCb. LHCb perche' esperimento maggiormente coinvolto nell'attivita'. Si e' convenuto che - allo stato attuale delle cose - sia escludere che includere DPM portera' comunque malcontento a qualcuno e che non averlo mutila il profilo tecnico del lavotro. L'idea e' quindi quella di capire meglio come muoversi con questa soluzione, e magari ritornare alla carica con JP. Stato: temporaneamente congelato.

UIs: Vincenzo ha trovato 3 UI (all'Universita' di Bologna) con harware decente che possono affiancarsi alle 2 gia' in uso. Forse alcuni firewall settings da guardare e quindi potra' darle ad Elisa.

Test futuri: si e' provato a buttare qualche idea su quali tests potrebbero essere interessanti ad affiancare l'attuale suite. Considerando un paio di necessita' (anche discusse al GSSD) di esperimento (consistency checks e cleaning up di dati) si e' pensato di studiare il comportamento (tempo) di un srmLs e srmRm di directory popolate diversamente di file o di alberi interi che simulano il contenuto di una produzione. Riccardo solleva  la necessita' di definire criteri per normalizzare questi tests (approccio molto complesso).

Altre proposte  di tests verranno fatte circolare via mail (tenendo comunque a mente lo use case di una VO) e quindi scritti su queste pagine.

[*] Da interazioni successive con Tigran sembra che sia preferibile l'upgrade di tutto il sistema (dCache + CHIMERA), e la nuova versione di tutto sarà disponibile fra domani o lunedì. Non appena procediamo all'upgrade, renderemo di nuovo disponibile il sistema per i test.

-- RobertoSantinel - 11 Oct 2007