\uD83D\uDDD3 Date
\uD83D\uDC65 Participants
Lancs: Matt Doidge Gerard, Steven
Glasgow: Sam
Apologies:
\uD83E\uDD45 Goals
List of Epics
New tickets
Consider new functionality / items
Detailed discussion of important topics
Site report activity
\uD83D\uDDE3 Discussion topics
Current status of Echo Gateways / WNs testing
Recent sandbox’s for review / deployments:
Item | Presenter | Notes | |
|---|---|---|---|
Deployment plan and changes anticipated before Christmas | Change freeze ~ today. new gateways awaiting updated AAAA the bug fix (below) | ||
bugfix for calculating striper objects in direct reads | https://github.com/stfc/xrootd-ceph/pull/50 Any further comments on the PR; or ready to merge ?
Katy Ellis to confirm a successful file dump read. File dump read failed for ‘unrelated’ reasons (auth failure) | ||
Gateway: observations and changes | Change the CMSD configuration to increase the frequency of load reporting / calculation  Tom to add slides | ||
Checksums fixes | Deployment appears to improve that metadata retrieval time at the checksum app layer, but not from the user client layer … It is indeed possible to remove stale checksum check in a dedicated checksum library. This is now being tested on ceph-gw8. Very preliminary results look good.  | ||
Prefetch studies and WN changes | New tests with     | ||
Deletion studies through RDR | Requirements from ATLAS VO (Alessandra): 11266 deletions/h of 3GiB files. We are mean seeing deletion times for 3GiB files of 0.5 - 4 seconds, however there are some large outliers. (Taken from 10 deletions of 3GiB batches, 500 files in each batch).  Current deletion times to delete a batch of 500 3GiB files average around 30s (with some large outliers, however). Extrapolating from the average would suggest a bulk deletion rate of 60,000 files per hour is achievable within RAL, using the CERN deletion timing program. It would be instructive to find test whether the deletion mechanism that ATLAS will use during DC24 (FTS?) is able to achieve acceptable deletion rates. An example of the variation in range of deletion times (plots from 07:30 this morning and 11:40):   Now testing deletion times with different concurrency levels (20 and 40). First results are that using 40 results in a lower overall deletion time, hence a higher deletion rate. To delete 500, 3 GiB files takes 14s with 40 threads, against 18s with 20 threads. However, mean and median times are slightly larger with 40 threads (1.1s for both median and mean, against 0.6 and 0.7 for 20 threads). The measurements with 20 and 40 threads were taken one after the other (within five minutes), so I don’t think that ECHO would have been performing much differently within that time range. Will run multiple tests at varying levels of concurrency to get more reliable stats, depending on what I find from the following: As the DC24 deletions involve Rucio invoking FTS, I’m started running bulk deletions with RAL FTS to observe how many deletion jobs run at any time. I’m discussing with Alessandra and Mihai what level of concurrency we might expect from CERN FTS during DC24. | ||
Tokens testing | XRD-63 - Getting issue details... STATUS can either have SAM tests passing OR the correct set of permissions. scitokens.trace probably doesn’t alter the results now. | ||
SKA Gateway box | /wiki/spaces/UK/pages/215941180 Deneb-dev now connected to the xrootd01 box. | ||
WN Xcache issue | futex lock hard locking xcache proxy on WNs (possibly occurrence of https://github.com/xrootd/xrootd/issues/1979 ) |
on GGUS:
Site reports
Lancaster - Leaned towards dual-CPU hosts for our new gateways. As discussed potential move towards “production” users doing r/w over CEPHFS.
Glasgow -