DDM ops will declare them to Rucio and the files will be deleted by Reaper (Rucio deletion agent)
Good opportunity to try deletion through HTTP/WebDAV doors
US will look into this
Next steps: Rucio will take care of inconsistencies between dataset definition and file catalog when migrated
For inconsistencies between file catalog and storage elements:
DDM ops is adapting scripts described in DDM ops twiki to work with Rucio dumps
Consistency check tool (CCC) developed in MWT2 could be useful, sites and cloud squads could discuss with MWT2 experts if the tool can be used for their sites)
Discuss any deletion of dark data in atlas-dq2-ops e-group or in ATLDDMOPS JIRA
sim: : Discrepancy between number of events requested and processed (needs JIRA)
pile: Issue with memory problems some parameters do not seem to be passed to the transform
post-prod: retry implemented and seems to work but need to test behavior for rest of the chain in JEDI
DC14
8TeV (pile): still queuing in the system with 55Mevents
13 TeV (simul): still queuing in the system with 120 Mevents (80M mcore)
MCore: present throughput is enough
AMOD/ADCoS
Central services degraded - ATLAS_DDM_VOBOX lyon, cnaf
FTS3 Update: short failure period in all clouds
Twiki pages down for a few hours on Sunday
Taiwan network problems, solved Monday
SARA MCTAPE full - dCache not deleting files although space is reclaimable - bug reported
Grid not completely full during last week
Jul 15-16 about 25-30% of resources underutilized
Causes still being investigated. Were some DDM transfers stuck/delayed due to staging SS node with credential errors or restarts
Large number of DDM lookup error caused many jobs stuck in WAITING and not going to ASSIGNED
AOB
Staging issues caused when same tape holds different sets of data. Repeated back and forth of the tape causes delay and stress to systems. More on this to be discussed at future meetings
DAST: 2 of North America shifters will be lost in the next weeks, putting us in crisis mode again.
New draft for data placement strategy being circulated to ADC and CREM mailing list.
2 main points:
All data will have a lifetime, also the ones on tape.
There should be very few things pinned on disk. The data on disks should be organized based on priority, priority still to be defined, based on frequency of access in the past and forecast of usage for the future.
More traffic most probably from/to tape
The draft currently discusses strategy, the implementations will be done incrementally.
Need time to switch from classic panda to JEDI (also bigpandamon). Maybe next week?
ACTION ITEM FOR SITES: Sites please regularly check and confirm that your historical APEL data has been published and looks correct when comparing with batch system utilization
See example steps circulated by D. Qing (20100406)