---
# System prepended metadata

title: Untitled

---

## CVMFS coordination meeting (2022-02-09)

### CernVM workshop @ Amsterdam (Sept 12-14 2022)

- https://indico.cern.ch/e/cvm22
- registration is open
    - you can still change from in-person to remote or vice versa later on
- suggestions for talks welcome
- mixed physical/virtual?
- co-located with EESSI commumity meeting on Sept 15-16?
- talk on MPI startup with CVMFS? or running MPI software served through CVMFS in general?

### CernVM-FS 2.9.1

- preparing release
- fixing last bugs
- nightly build available for CernVM-FS 2.9.1 that includes GeoAPI fix
    - cfr. https://sft.its.cern.ch/jira/browse/CVM-2052
    - see https://ecsft.cern.ch/dist/cvmfs/nightlies/cvmfs-git-3202

### Other

- planning to move away from JIRA issue tracker to GitHub issues at https://github.com/cvmfs/cvmfs/issues

### Q&A

- sfleisch: warning when ingesting large files (>1GB), is this still relevant?
    - in this case as a Singularity container image
    - Dave: bad idea in general
    - quite demanding on garbage collection when image is updated
    - ingested container image unpacked is better, also allows running containers unpriviledged
    - large files are downloaded in chunks as needed
    - for container images CVMFS will pull in way more than is needed
    - SIF files will also be unpacked on every client node again, lots of overhead
    - adding it to unpacked.cern.ch is an option: https://gitlab.cern.ch:8443/unpacked/sync
- sfleisch: remote publishing through gateway
    - problem occured where publishing/aborting/starting new transaction was not possible
    - no way to recover from this for user...
    - worked around by manually removing state files on publisher (`transaction.lock` + marked of ongoing transaction)
    - Radu: open issues on this to make this more robust
        - removing these files when only a singly publisher is fine
        - removing locks should be done with care of course
        - plan to work on tool to do emergency recovery for situations like this
    - seems like `cvmfs_server abort` was screwing up?
- sfleisch: command to get revision version of given repo on Stratum-0 or Stratum-1
    - Radu: can be obtained via repository manifest: `.cvmfspublished` in root of repository
        - Dave: best check contents of this file via `cat -v` (`--show-nonprinting` to avoid trouble with binary data that confuses `grep`)
        - `cat -v /srv/cvmfs/dirac.egi.eu/.cvmfspublished | grep ^S`
    - Dave: also extended attribute available on client
    - interesting to verify that all Stratum-1 are serving same revision
    - Dave: cvmfs-servermon (https://github.com/cvmfs-contrib/cvmfs-servermon) checks on Stratum-1 whether or not snapshots are broken
        - monitoring differently turned out to be difficult to come with a reliable algorithm
        - RPMs are available via cvmfs-contrib repo
- John Steven De Stefano: corruption problem with Stratum-1
    - related to disk corruption?
    - Dave: may want to disable core dumps on that machine?
    - have done so, reluctantly
    - Radu: please create issue with details

### Next meeting

- Tue March 8th 2022 - 16:00 UTC?
    - see https://indico.cern.ch/category/5485