AMS02:
- not in hurry, prefers to migrate to EOSAMS02 after mid September
(until then, critical time for analysis prefers to keep system changes minimal)
- will run 2-3 weeks of fast reconstruction campaign starting end of April / June
- is OK to give 2 PB of free space from EOSPUBLIC to EOSAMS02
- in general xrootd is used in 95% of cases to read/write data —> EOS expects
only minimal inconsistencies due to switching FUSEx to the new instance.
AMS is OK with few days out of sync between public and ams02 instances due to FUSEx migration.
- data in /eos/ams/Data and /eos/ams/MC are 99% of the time only read, occasionally (1%) overwritten,
no file updates —> AMS agrees to use erasure encoding
Actions:
- make sure that the collaboration connects always via ‘eosams’ alias and no-one uses ‘eospublic’
- check if /eos/afs/ could be removed/hidden on EOSPUBLIC and confirm to EOS Ops
- send EOS Ops the config of AMS machines which have FUSE configured by hand; perhaps changing to new FUSEx
EOS:
- will continue developing/speeding up sync scripts and migrating data to the new instance
without interfering with the current activity on EOSPUBLIC
Actions:
- send list of areas where we need help
(e.g. change of ownership from non existing user to ‘ams’)
- install 2 PB buffer space from EOSPUBLIC to EOSAMS02 to start migration of /eos/ams/
- continue migrating remaining areas and reinstall the 2PB on EOSPUBLIC as soon as possible
