NEMO2/Workspaces: Difference between revisions
mNo edit summary |
|||
| Line 122: | Line 122: | ||
=== Group workspace (recommended) === |
=== Group workspace (recommended) === |
||
<syntaxhighlight lang="bash"> |
|||
| ⚫ | |||
ws_allocate -g myWs 100 # Group-readable (read-only for group) |
|||
| ⚫ | |||
ws_allocate -G bw12a001 myWs 100 # Example: project group bw12a001 |
|||
</syntaxhighlight> |
|||
| ⚫ | |||
<syntaxhighlight lang="bash"> |
|||
ws_allocate -x -u owner myWs 100 |
|||
</syntaxhighlight> |
|||
| ⚫ | |||
Using <tt>-G</tt> also enables smooth handover when team members leave — see [[NEMO2/Workspaces/Advanced_Features#Workspace_Handover|Workspace Handover]]. |
Using <tt>-G</tt> also enables smooth handover when team members leave — see [[NEMO2/Workspaces/Advanced_Features#Workspace_Handover|Workspace Handover]]. |
||
| Line 131: | Line 139: | ||
<pre> |
<pre> |
||
groupname: |
groupname: bw12a001 |
||
</pre> |
</pre> |
||
{{Note|Your project group name (e.g. <tt>bw12a001</tt>) is typically assigned by your HPC site. Use <tt>groups</tt> on the command line to list all groups you belong to.}} |
|||
=== Share after creation === |
=== Share after creation === |
||
| Line 138: | Line 148: | ||
If you didn't use <tt>-g</tt>/<tt>-G</tt> at creation, share read-only with <tt>ws_share</tt>: |
If you didn't use <tt>-g</tt>/<tt>-G</tt> at creation, share read-only with <tt>ws_share</tt>: |
||
<syntaxhighlight lang="bash"> |
|||
$ ws_share share myWs alice bob # Grant read access |
|||
ws_share share myWs alice bob # Grant read access |
|||
ws_share list myWs # Show who has access |
|||
ws_share unshare myWs alice # Remove access |
|||
</syntaxhighlight> |
|||
'''Advanced sharing:''' [[NEMO2/Workspaces/Advanced_Features#Sharing|Sharing guide]] for ACL-based per-user permissions. |
'''Advanced sharing:''' [[NEMO2/Workspaces/Advanced_Features#Sharing|Sharing guide]] for ACL-based per-user permissions. |
||
Revision as of 15:01, 20 May 2026
Note: This is the updated Workspaces guide for NEMO2. For other clusters please use: Workspace.
Workspace tools provide temporary storage on NEMO's fast parallel filesystem (Weka). They are meant for data that needs to persist longer than a single job, but not permanently.
For advanced features — user config (~/.ws_user.conf), reminders, quotas, workspace handover, and more — see Advanced Features.
What are Workspaces?
Use workspaces for:
- Jobs generating intermediate data
- Data shared between multiple compute nodes
- Multi-step workflows
Don't use workspaces for:
- Permanent storage (use HOME or project directories)
- Single-node temporary files (use $TMPDIR instead)
Important - Read First
- No Backup: Data is not backed up and will be automatically deleted after expiration
- Time-limited: Maximum lifetime is 100 days, up to 100 extensions
- Email Reminders: You receive email notifications before expiration
- Backup Important Data: Copy results to permanent storage before expiration
Command Overview
- ws_allocate - Create or extend workspace
- ws_list - List your workspaces
- ws_find - Find workspace path (for scripts)
- ws_extend - Extend workspace lifetime
- ws_release - Release (delete) workspace
- ws_restore - Restore expired/released workspace
- ws_register - Create symbolic links
All commands support -h for help.
Quick Start
| Task | Command |
|---|---|
| Create workspace (100 days) | ws_allocate myWs 100 |
| Create group workspace | ws_allocate -G groupname myWs 100 |
| List all workspaces | ws_list |
| See what expires soon | ws_list -Rr |
| Find path (for scripts) | ws_find myWs |
| Extend by 100 days | ws_extend myWs 100 |
| Delete workspace (permanent, next nightly run) | ws_release myWs |
| Restore expired workspace (30d grace) | ws_restore -l then ws_restore oldname newname |
Creating Workspaces
Create a workspace with a name and lifetime in days:
$ ws_allocate myWs 100
Returns:
/work/classic/$USER-myWs
Capture path in variable:
$ WORKSPACE=$(ws_allocate myWs 100) $ cd "$WORKSPACE"
Important: Running the same command again is safe - returns the existing workspace path.
Listing Workspaces
$ ws_list # List all workspaces $ ws_list -Rr # Sort by remaining time, soonest first $ ws_list -g # Show group workspaces
Extending Workspaces
$ ws_extend myWs 100 # Extend by 100 days from now
Alternative: ws_allocate -x myWs 100
Each extension consumes one of your available extensions (100 total).
Releasing Workspaces
$ ws_release myWs
The workspace becomes inaccessible immediately and is permanently deleted at the next nightly expirer run. Do not rely on recovering a released workspace.
Restoring Workspaces
Recover workspaces that expired naturally (reached end of lifetime) within the 30-day grace period:
$ ws_restore -l # (1) List restorable workspaces $ ws_allocate restored 100 # (2) Create target workspace $ ws_restore username-myWs-0 restored # (3) Restore
Important: Use the full name from ws_restore -l (with username and timestamp), not the short name. Released workspaces (via ws_release) can also be restored, but only until the next nightly expirer run — after that they are permanently deleted.
Sharing Workspaces
Group workspace (recommended)
ws_allocate -g myWs 100 # Group-readable (read-only for group)
ws_allocate -G projectgroup myWs 100 # Group-writable (recommended for teams)
ws_allocate -G bw12a001 myWs 100 # Example: project group bw12a001
Anyone in the group can use ws_list -g to see the workspace and extend it with:
ws_allocate -x -u owner myWs 100
Using -G also enables smooth handover when team members leave — see Workspace Handover.
Set default group in ~/.ws_user.conf:
groupname: bw12a001
If you didn't use -g/-G at creation, share read-only with ws_share:
ws_share share myWs alice bob # Grant read access
ws_share list myWs # Show who has access
ws_share unshare myWs alice # Remove access
Advanced sharing: Sharing guide for ACL-based per-user permissions.