Overview of CL's storage
Context
The storage solution hosting CLWORK and CLFILES was discontinued in early 2025 due to deep reorganization of CL's IT. The new CL Storage replicates this structure, where each user and each project have a quota on a backed-up storage, and a larger quota on a faster but non-backed-up, mirrored storage. This networked storage is accessible from every server on CL's infra.
| Network location | Location on our servers | Redundancy level |
|---|---|---|
| idnas21.uzh.ch:/cl_02/home | /home | RAID mirroring, backups |
| idnas21.uzh.ch:/cl_02/projects | /projects | RAID mirroring, backups |
| idnas21.uzh.ch:/cl_01/data | /data | RAID mirroring only |
| idnas21.uzh.ch:/cl_01/projects-data | /projects-data | RAID mirroring only |
Personal storage
The locations /home and /data are dedicated to individual storage. To reach them, you can cd /home/$USER or cd /data/$USER.
Group storage
The locations /projects and /projects-data are dedicated to group/project storage.
In order to access i.e. /projects/text, you need to be a member of the group .l.cl.text-members. To quickly check if you're a member of the relevant group, you can run the command id, browse through the output and see if the name of the relevant group is there.
Disambiguation
Upon getting access to a specialized server (GPU server or CPU server), you get a personal space on its "scratch" storage. Scratch storage is local, non-backed-up storage. It's intended to provide a way to have fast, non-networked storage for you to hold datasets that you're working on, temporarily store the output of your jobs and so on. There's no guarantee for long-term storage on it: we need to reserve the right to delete data older than 30 days if it becomes necessary (if the scratch partition becomes full, if volume resizing becomes necessary and so on).
Limitations of CL's storage
The two main limitations are linked to this storage being an NFS volume:
Git operations
Git operations that require calls to fsync are not possible on this type of NFS.
It's advised to use the scratch folders for working with git. The workflow is described in detail in this dedicated article.
Acces complications
The way it's configured by ZI, NFS 4.2 shares still incur in old Unix limitations, particularly it has a limit of 16 group memberships per user. This means that if your user belongs to more than 16 groups, the NFS server will only evaluate the first 16 group memberships that are communicated by the machine accessing the storage (the server you're SSh'ing to).
We have come up with ways around this (preselection and ordering occur in the background when the calls are made to the NFS servers), but this is not a perfect system. So if you've been here long enough to be involved in multiple projects and have a long list of accesses granted to you, checking for this without sudo access is not easy, but you can kinda-check.
Run the command id and if you see a very long list of .l.cl.* groups, this might be the culprit.
There's no easy solution, but the kinda-solution is to log out of the server,. log back in and try again to reach your section of the storage.
If the problem persists, please get in touch with (infra@cl.uzh.ch)[mailto:infra@cl.uzh.ch].