NEMO2/Workspaces/Advanced Features: Difference between revisions
mNo edit summary |
|||
| (26 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
For basic daily usage see the main [[NEMO2/Workspaces|Workspaces]] guide. |
|||
__TOC__ |
|||
== Almost Complete Command Reference == |
|||
== Creating Workspaces == |
|||
{| class="wikitable" |
|||
|- |
|||
!style="width:40%" | Task |
|||
!style="width:60%" | Command |
|||
|- |
|||
|Create workspace for 30 days |
|||
|<tt>ws_allocate myWs 30</tt> |
|||
|- |
|||
|Create with custom email |
|||
|<tt>ws_allocate -m custom@example.com -r 3 myWs 30</tt> |
|||
|- |
|||
|Create group-writable workspace |
|||
|<tt>ws_allocate -G groupname myWs 30</tt> |
|||
|- |
|||
|Create on specific filesystem |
|||
|<tt>ws_allocate -F filesystem myWs 30</tt> |
|||
|- |
|||
|List all your workspaces |
|||
|<tt>ws_list</tt> |
|||
|- |
|||
|List by remaining time |
|||
|<tt>ws_list -R</tt> |
|||
|- |
|||
|List available filesystems |
|||
|<tt>ws_list -l</tt> or <tt>ws_find -l</tt> |
|||
|- |
|||
|Find workspace path |
|||
|<tt>ws_find myWs</tt> |
|||
|- |
|||
|Extend workspace by 40 days |
|||
|<tt>ws_extend myWs 40</tt> or <tt>ws_allocate -x myWs 40</tt> |
|||
|- |
|||
|Share with another user |
|||
|<tt>ws_share share myWs username</tt> |
|||
|- |
|||
|List shared users |
|||
|<tt>ws_share list myWs</tt> |
|||
|- |
|||
|Send calendar reminder |
|||
|<tt>ws_send_ical myWs user@example.com</tt> |
|||
|- |
|||
|Release workspace |
|||
|<tt>ws_release myWs</tt> |
|||
|- |
|||
|List restorable workspaces |
|||
|<tt>ws_restore -l</tt> |
|||
|- |
|||
|Register workspace links |
|||
|<tt>ws_register ~/workspaces</tt> |
|||
|} |
|||
$ ws_allocate myWs 100 |
|||
== Multiple Filesystem Locations == |
|||
Returns the workspace path, e.g. <tt>/work/classic/$USER-myWs</tt>. |
|||
{| class="wikitable" |
|||
Running the same command again is safe — it returns the existing workspace path. |
|||
|- |
|||
!style="width:40%" | Works on cluster |
|||
!style="width:10%" | bwUC 3.0 |
|||
!style="width:10%" | BinAC2 |
|||
!style="width:10%" | Helix |
|||
!style="width:10%" | JUSTUS 2 |
|||
!style="width:10%" | NEMO2 |
|||
|- |
|||
|<tt>-F</tt> option (multiple filesystems) |
|||
|style="background-color:#90EE90; text-align:center;" | ✓ |
|||
|style="background-color:#FFB6C1; text-align:center;" | ✗ |
|||
|style="background-color:#FFB6C1; text-align:center;" | ✗ |
|||
|style="background-color:#FFB6C1; text-align:center;" | ✗ |
|||
|style="background-color:#FFB6C1; text-align:center;" | ✗ |
|||
|} |
|||
'''Capture path in variable:''' |
|||
Some clusters offer multiple filesystem locations for workspaces with different characteristics: |
|||
$ WORKSPACE=$(ws_allocate myWs 100) |
|||
'''bwUniCluster 3.0:''' |
|||
$ cd "$WORKSPACE" |
|||
* Default workspace filesystem (Lustre) |
|||
* Flash-based workspace filesystem (<tt>ffuc</tt>) - for KIT/HoreKa users only |
|||
** Lower latency and better performance for small files |
|||
** SSDs instead of hard disks |
|||
** Shared between bwUniCluster 3.0 and HoreKa |
|||
'''Common options:''' |
|||
'''Example creating workspace on flash filesystem:''' |
|||
$ ws_allocate - |
$ ws_allocate -g myWs 100 # Group-readable workspace |
||
$ ws_allocate -G projectgroup myWs 100 # Group-writable workspace |
|||
$ ws_allocate -r 7 myWs 100 # Reminder 7 days before expiry |
|||
Use <tt>ws_list -l</tt> or <tt>ws_find -l</tt> to see available filesystem locations on your cluster. |
|||
$ ws_allocate -c "ML training data" myWs 100 # Add comment (shown in ws_list -l) |
|||
$ ws_allocate -x myWs 100 # Extend existing workspace |
|||
== Detailed ws_allocate Options == |
|||
$ ws_allocate -x -u alice myWs 100 # Extend Alice's group workspace |
|||
$ ws_allocate -r 7 -x myWs 0 # Update reminder only (no extension) |
|||
{| class="wikitable" |
|||
|- |
|||
!style="width:40%" | Works on cluster |
|||
!style="width:10%" | bwUC 3.0 |
|||
!style="width:10%" | BinAC2 |
|||
!style="width:10%" | Helix |
|||
!style="width:10%" | JUSTUS 2 |
|||
!style="width:10%" | NEMO2 |
|||
|- |
|||
|<tt>ws_allocate -x -u</tt> (extend other user's workspace) |
|||
| style="text-align:center;" | |
|||
| style="text-align:center;" | |
|||
| style="text-align:center;" | |
|||
| style="text-align:center;" | |
|||
|style="background-color:#90EE90; text-align:center;" | ✓ |
|||
|} |
|||
=== Basic Usage === |
|||
Execution of: |
|||
$ ws_allocate myWs 30 |
|||
e.g. returns: |
|||
Workspace created. Duration is 720 hours. |
|||
Further extensions available: 3 |
|||
/work/workspace/scratch/username-myWs-0 |
|||
The command returns the path to the new directory, which can be captured in a variable: |
|||
$ SCRDIR=$(ws_allocate myWs 10) |
|||
'''Important:''' Creating a workspace a second time with the same command is a no-operation - it always returns the same path. This makes it safe and encouraged to use such a line in batch jobs which are part of a series of jobs working on the same data, no matter if the job was running before or not. |
|||
=== All Options and When to Use Them === |
|||
{| class="wikitable" |
{| class="wikitable" |
||
|- |
|- |
||
!style="width:20%" | Option |
!style="width:20%" | Option |
||
!style="width: |
!style="width:80%" | Description |
||
!style="width:40%" | When to Use |
|||
|- |
|||
|<tt>-F <filesystem></tt> |
|||
|Specify the filesystem where the workspace should be created |
|||
|'''Optional''' - Most clusters have only one default filesystem. Use only when you need specific storage characteristics (speed, capacity) or to balance load across multiple filesystems. List available locations with <tt>ws_list -l</tt> or <tt>ws_find -l</tt> |
|||
|- |
|- |
||
|<tt>-g</tt> |
|<tt>-g</tt> |
||
| |
|Group-readable workspace |
||
|'''Recommended''' when working in a team and others need to read your data. The workspace will be visible to group members with <tt>ws_list -g</tt> |
|||
|- |
|- |
||
|<tt>-G <groupname></tt> |
|<tt>-G <groupname></tt> |
||
| |
|Group-writable workspace. Set default in <tt>~/.ws_user.conf</tt> |
||
|'''Recommended''' for collaborative work where team members need to write data. Ensures all created files belong to the group. Can be set as default in <tt>~/.ws_user.conf</tt> |
|||
|- |
|- |
||
|<tt>-m < |
|<tt>-m <email></tt> |
||
| |
|Custom email for reminders (overrides identity provider email) |
||
|'''Optional''' - Email addresses come from your identity provider. Only use this option to override with a different address. Can be set as default in <tt>~/.ws_user.conf</tt> |
|||
|- |
|- |
||
|<tt>-r <days></tt> |
|<tt>-r <days></tt> |
||
| |
|Reminder n days before expiration |
||
|- |
|||
|'''Optional''' - Email reminders are sent automatically. Use this only to customize when the reminder starts (e.g., 3, 5, or 7 days before). Can be set as default in <tt>~/.ws_user.conf</tt> |
|||
|<tt>-c <comment></tt> |
|||
|Comment shown in <tt>ws_list -l</tt> |
|||
|- |
|- |
||
|<tt>-x</tt> |
|<tt>-x</tt> |
||
|Extend |
|Extend existing workspace |
||
|Use when you need more time. Each extension consumes one of the available extensions |
|||
|- |
|- |
||
|<tt>-u <username></tt> |
|<tt>-u <username></tt> |
||
|Target another user's workspace (requires <tt>-G</tt>) |
|||
|Used with <tt>-x</tt> to extend another user's workspace |
|||
|Use when a group member is absent and their shared workspace needs extension. Requires group write access <tt>-G</tt> |
|||
|- |
|||
|<tt>-c <comment></tt> |
|||
|Add a comment to the workspace |
|||
|Use to document the purpose of the workspace for yourself and collaborators |
|||
|- |
|||
|<tt>-d <duration></tt> |
|||
|Duration in days (alternative to positional argument) |
|||
|Use if you prefer explicit option syntax: <tt>ws_allocate -n myWs -d 30</tt> |
|||
|- |
|||
|<tt>-n <name></tt> |
|||
|Workspace name (alternative to positional argument) |
|||
|Use if you prefer explicit option syntax: <tt>ws_allocate -n myWs -d 30</tt> |
|||
|} |
|} |
||
'''Using workspaces in batch jobs:''' |
|||
=== Duration Settings === |
|||
Create the workspace once on the login node, then use <tt>ws_find</tt> in the job script: |
|||
If you do not specify a lifetime, a default lifetime will be used (see the [[Workspaces/Advanced_Features#Cluster-Specific_Workspace_Limits|Cluster-Specific Workspace Limits]])). The maximum lifetime may be limited by the operations team. If you specify a longer lifetime, it will be capped to the maximum, and you will see a message that it was changed. |
|||
<pre> |
|||
For more information read the program's help: <tt>$ ws_allocate -h</tt> or <tt>man ws_allocate</tt> |
|||
#!/bin/bash |
|||
#SBATCH --job-name=my_job |
|||
WORKSPACE=$(ws_find myProject) |
|||
== Advanced ws_list Options == |
|||
cd "$WORKSPACE" |
|||
./my_program --input input.dat --output results.dat |
|||
Beyond the basic options shown in the main [[Workspaces]] guide, <tt>ws_list</tt> supports additional sorting and filtering: |
|||
</pre> |
|||
=== User Defaults: ~/.ws_user.conf === |
|||
* <tt>-N</tt> - Sort by name (alphabetical) |
|||
* <tt>-C</tt> - Sort by creation date |
|||
* <tt>-t</tt> - Terse format |
|||
* <tt>-v</tt> - Verbose format with all metadata |
|||
* <tt>-r</tt> - Reverse sort order |
|||
* <tt>-F <location></tt> - List workspaces on specific filesystem only |
|||
* <tt>-g</tt> - List group workspaces (if you're in the same group) |
|||
* <tt>-l</tt> - List available filesystem locations |
|||
Set defaults so you never forget important options. The file is in YAML format: |
|||
To list expired workspaces, see [[#Restore_an_Expired_Workspace|Restore an Expired Workspace]]. |
|||
<pre> |
|||
For more information: <tt>$ ws_list -h</tt> or <tt>man ws_list</tt> |
|||
duration: 100 |
|||
reminder: 7 |
|||
groupname: projectgroup |
|||
</pre> |
|||
<div style="border: 3px solid #dc3545; padding: 15px; background-color: #f8d7da; margin: 10px 0;"> |
|||
== Advanced ws_find Options == |
|||
'''Important:''' The first line must be a setting, not a comment. Some versions interpret a leading <tt>#</tt> as an email address. |
|||
</div> |
|||
<tt>ws_find</tt> can search workspaces on specific filesystems: |
|||
* <tt>-F <filesystem></tt> - Search workspace on specific filesystem |
|||
* <tt>-l</tt> - List valid filesystem names |
|||
== Advanced ws_extend Options == |
|||
Beyond the basic extension shown in the main [[Workspaces]] guide: |
|||
* <tt>-F filesystem</tt> - Extend workspace on specific filesystem |
|||
* <tt>ws_allocate -x</tt> - Alternative command for extension |
|||
* You can shorten workspace lifetime even if no extensions are available |
|||
* Group members can extend group workspaces. Requires group write access <tt>ws_allocate -G</tt>: |
|||
<tt>ws_allocate -x -u <username> <workspace_id> <days></tt> |
|||
'''Update reminder only''' (without extending): |
|||
$ ws_allocate -r <days> -x <workspace> 0 |
|||
With the config above, <tt>ws_allocate myWs</tt> automatically creates a 100-day workspace with a 7-day reminder for the default group — no extra flags needed. |
|||
== Getting Reminders == |
|||
{| class="wikitable" |
{| class="wikitable" |
||
|- |
|- |
||
!style="width: |
!style="width:25%" | Setting |
||
!style="width: |
!style="width:75%" | Description |
||
!style="width:10%" | BinAC2 |
|||
!style="width:10%" | Helix |
|||
!style="width:10%" | JUSTUS 2 |
|||
!style="width:10%" | NEMO2 |
|||
|- |
|- |
||
|<tt>duration:</tt> |
|||
|Email reminders |
|||
|Default lifetime in days |
|||
|style="background-color:#90EE90; text-align:center;" | ✓ |
|||
|style="background-color:#90EE90; text-align:center;" | ✓ |
|||
|style="background-color:#90EE90; text-align:center;" | ✓ |
|||
|style="background-color:#90EE90; text-align:center;" | ✓ |
|||
|style="background-color:#90EE90; text-align:center;" | ✓ |
|||
|- |
|- |
||
|<tt> |
|<tt>reminder:</tt> |
||
|Days before expiration for reminder |
|||
|style="background-color:#90EE90; text-align:center;" | ✓ |
|||
|- |
|||
|style="background-color:#FFB6C1; text-align:center;" | ✗ |
|||
|<tt>groupname:</tt> |
|||
|style="background-color:#90EE90; text-align:center;" | ✓ |
|||
|Default group for <tt>-G</tt> (see [[#Sharing|Sharing]]) |
|||
|style="background-color:#FFB6C1; text-align:center;" | ✗ |
|||
|- |
|||
|style="background-color:#FFB6C1; text-align:center;" | ✗ |
|||
|<tt>mail:</tt> |
|||
|Override notification email (optional) |
|||
|} |
|} |
||
== Listing Workspaces == |
|||
'''Email reminders:''' Sent automatically using email addresses from your identity provider. You can customize the reminder timing with <tt>-r <days></tt>: |
|||
$ |
$ ws_list # All your workspaces |
||
$ ws_list -Rr # Sort by remaining time (soonest first) |
|||
$ ws_allocate -r 3 -m custom@example.com myWs 30 # Custom timing and different email address |
|||
$ ws_list -g # Include group workspaces |
|||
Example output: |
|||
'''Calendar reminder''' (bwUniCluster 3.0, Helix): |
|||
$ ws_send_ical <workspace> <email> |
|||
'''User defaults''' in <tt>~/.ws_user.conf</tt> (YAML format): |
|||
<pre> |
<pre> |
||
id: myWs |
|||
mail: reach@me.here # Optional - only if you want to override the email from identity provider |
|||
workspace directory : /work/classic/$USER-myWs |
|||
duration: 10 # Default workspace lifetime |
|||
remaining time : 6 days 23 hours |
|||
reminder: 3 # Days before expiration to send reminder |
|||
creation time : Thu Apr 17 09:23:41 2025 |
|||
groupname: mygroup # Default group for -G option |
|||
expiration time : Mon May 26 09:23:41 2025 |
|||
available extensions : 98 |
|||
</pre> |
</pre> |
||
=== Example ~/.ws_user.conf Configuration === |
|||
{| class="wikitable" |
{| class="wikitable" |
||
|- |
|||
!style="width:40%" | Works on cluster |
|||
!style="width:10%" | bwUC 3.0 |
|||
!style="width:10%" | BinAC2 |
|||
!style="width:10%" | Helix |
|||
!style="width:10%" | JUSTUS 2 |
|||
!style="width:10%" | NEMO2 |
|||
|- |
|- |
||
!style="width:15%" | Option |
|||
|<tt>~/.ws_user.conf</tt> configuration file |
|||
!style="width:85%" | Description |
|||
|style="background-color:#90EE90; text-align:center;" | ✓ |
|||
|style="text-align:center;" | |
|||
|style="text-align:center;" | |
|||
|style="text-align:center;" | |
|||
|style="background-color:#90EE90; text-align:center;" | ✓ |
|||
|} |
|||
Here's a complete example configuration file that sets useful defaults: |
|||
<pre> |
|||
# ~/.ws_user.conf - Workspace tool defaults |
|||
# This file uses YAML syntax |
|||
# Email address for expiration reminders (optional) |
|||
# If not set, email from your identity provider is used automatically |
|||
# Only uncomment this line if you need to use a different email address |
|||
# mail: custom.email@example.com |
|||
# Default workspace duration in days |
|||
# Set this to your typical workspace lifetime to avoid typing it every time |
|||
duration: 30 |
|||
# Reminder timing in days before expiration |
|||
# You will receive an email this many days before workspace expires |
|||
# Recommended: 3-7 days to give yourself time to extend or backup data |
|||
reminder: 5 |
|||
# Default group name for collaborative workspaces |
|||
# If you always work with the same group, set this to avoid typing -G groupname |
|||
# Uncomment and set your group name below: |
|||
# groupname: bw16e001 |
|||
</pre> |
|||
'''To create this file:''' |
|||
$ nano ~/.ws_user.conf |
|||
Then paste the configuration above and adjust the values to your needs. |
|||
'''Benefits of using ~/.ws_user.conf:''' |
|||
* Avoid typing the same options repeatedly |
|||
* Ensures consistent settings across all workspace operations |
|||
* Simplifies commands: <tt>ws_allocate myWs</tt> instead of <tt>ws_allocate -r 5 myWs 30</tt> |
|||
* Automatic group collaboration setup when <tt>groupname</tt> is set |
|||
== Cooperative Usage (Group Workspaces and Sharing) == |
|||
When working in teams, workspaces can be shared in multiple ways. |
|||
<div style="border: 3px solid red; padding: 15px; background-color: #ffe6e6; margin: 10px 0;"> |
|||
'''WARNING: NEVER use chmod 777 or a+rwx on workspaces!''' |
|||
Do '''NOT''' make your workspace readable or writable by everyone (<tt>chmod 777</tt>, <tt>chmod a+rwx</tt>, or <tt>chmod o+rwx</tt>). This is a severe security risk: |
|||
* Anyone on the system can read, modify, or delete your data |
|||
* Malicious users can inject code into your workspace |
|||
* Your data and results become unreliable |
|||
* You violate security policies and may lose access privileges |
|||
'''Always use proper sharing methods:''' Use <tt>-g</tt>/<tt>-G</tt> flags, <tt>ws_share</tt>, or group-based permissions instead. |
|||
</div> |
|||
'''Important:''' Not all sharing methods are available on all clusters. The availability depends on: |
|||
* Filesystem type and ACL support |
|||
* Cluster-specific workspace tool configuration |
|||
* Unix group setup and permissions |
|||
If one sharing method doesn't work on your cluster, try an alternative approach. The <tt>-g</tt> and <tt>-G</tt> flags are most widely supported. |
|||
=== Group Workspaces === |
|||
{| class="wikitable" |
|||
|- |
|||
!style="width:40%" | Works on cluster |
|||
!style="width:10%" | bwUC 3.0 |
|||
!style="width:10%" | BinAC2 |
|||
!style="width:10%" | Helix |
|||
!style="width:10%" | JUSTUS 2 |
|||
!style="width:10%" | NEMO2 |
|||
|- |
|- |
||
|<tt>- |
|<tt>-l</tt> |
||
|Long listing (shows creation time, comment, extensions remaining) |
|||
|style="text-align:center;" | |
|||
|style="text-align:center;" | |
|||
|style="text-align:center;" | |
|||
|style="text-align:center;" | |
|||
|style="background-color:#90EE90; text-align:center;" | ✓ |
|||
|- |
|- |
||
|<tt>- |
|<tt>-R</tt> |
||
|Show remaining time as human-readable |
|||
|style="text-align:center;" | |
|||
|style="text-align:center;" | |
|||
|style="text-align:center;" | |
|||
|style="text-align:center;" | |
|||
|style="background-color:#90EE90; text-align:center;" | ✓ |
|||
|} |
|||
When a workspace is created with <tt>-g</tt> it becomes a group workspace that is visible to others with <tt>ws_list -g</tt> (if in same group), and is group readable: |
|||
$ ws_allocate -g myWs 30 |
|||
When created with <tt>-G <groupname></tt> the workspace becomes writable as well, and gets group sticky bit: |
|||
$ ws_allocate -G projectgroup myWs 30 |
|||
The group can be specified in the <tt>~/.ws_user.conf</tt> file as well. |
|||
'''Important:''' Group members can extend group-writable workspaces (created with <tt>-G</tt>) even if the original creator is absent: |
|||
$ ws_allocate -x -u <username> <workspace_id> <days> |
|||
This requires group write access to the workspace. This is useful when the workspace owner is unavailable and the workspace needs to be extended. |
|||
'''Recommendations:''' |
|||
* Use <tt>-g</tt> when team members only need to read your results |
|||
* Use <tt>-G</tt> for collaborative work where everyone writes data |
|||
* Set <tt>groupname</tt> in <tt>~/.ws_user.conf</tt> if you always work with the same group |
|||
=== Sharing with ws_share === |
|||
{| class="wikitable" |
|||
|- |
|||
!style="width:40%" | Works on cluster |
|||
!style="width:10%" | bwUC 3.0 |
|||
!style="width:10%" | BinAC2 |
|||
!style="width:10%" | Helix |
|||
!style="width:10%" | JUSTUS 2 |
|||
!style="width:10%" | NEMO2 |
|||
|- |
|- |
||
|<tt> |
|<tt>-r</tt> |
||
|Reverse sort order |
|||
| style="text-align:center;" | |
|||
| style="text-align:center;" | |
|||
| style="text-align:center;" | |
|||
| style="text-align:center;" | |
|||
|style="background-color:#90EE90; text-align:center;" | ✓ |
|||
|} |
|||
With <tt>ws_share</tt> you can share workspaces with users outside your group, using ACLs (if supported by underlying filesystem). |
|||
'''Note:''' This feature requires ACL support on the filesystem. If <tt>ws_share</tt> doesn't work on your cluster, use manual ACL commands (<tt>setfacl</tt>) or fall back to Unix group permissions. |
|||
'''Share workspace with users:''' |
|||
$ ws_share share myWs username1 username2 # Grant read access to one or more users |
|||
$ ws_share share -F filesystem myWs user1 # Share on specific filesystem |
|||
'''Unshare workspace from users:''' |
|||
$ ws_share unshare myWs username1 # Remove access from specific user(s) |
|||
$ ws_share unshare-all myWs # Remove access from all users |
|||
'''List users with access:''' |
|||
$ ws_share list myWs # Show all users with read access |
|||
These operations are applied to all files and directories in the workspace. |
|||
'''Options:''' |
|||
* <tt>-F <filesystem></tt>, <tt>--filesystem</tt>: Specify the workspace filesystem |
|||
* <tt>-h</tt>, <tt>--help</tt>: Show help message |
|||
'''Recommendation:''' Use <tt>ws_share</tt> for selective sharing with individual users, especially when they are not in your Unix group. |
|||
=== ACLs: Access Control Lists === |
|||
{| class="wikitable" |
|||
|- |
|||
!style="width:40%" | Works on cluster |
|||
!style="width:10%" | bwUC 3.0 |
|||
!style="width:10%" | BinAC2 |
|||
!style="width:10%" | Helix |
|||
!style="width:10%" | JUSTUS 2 |
|||
!style="width:10%" | NEMO2 |
|||
|- |
|- |
||
|<tt> |
|<tt>-s</tt> |
||
|Sort by creation time |
|||
| style="text-align:center;" | |
|||
|- |
|||
| style="text-align:center;" | |
|||
|<tt>-g</tt> |
|||
| style="text-align:center;" | |
|||
|Include group workspaces (not just owned) |
|||
| style="text-align:center;" | |
|||
|style="background-color:#90EE90; text-align:center;" | ✓ |
|||
|} |
|} |
||
== Finding Workspace Paths == |
|||
ACLs (Access Control Lists) provide fine-grained permission control beyond standard Unix permissions. They allow sharing with specific users and groups, and support default ACLs that new files automatically inherit. |
|||
Returns the full path — primarily useful in scripts: |
|||
'''Note:''' ACL support varies by filesystem. Not all clusters support ACLs on workspace filesystems. If ACL commands fail, use regular Unix permissions instead. |
|||
$ ws_find myWs |
|||
'''Key advantages:''' |
|||
/work/classic/$USER-myWs |
|||
* Share with specific users (not just groups) |
|||
* Default ACLs - new files automatically inherit permissions |
|||
* More flexible than Unix permissions |
|||
$ WORKSPACE=$(ws_find myWs) |
|||
'''Note:''' ACLs take precedence over standard Unix permissions. View ACLs with <tt>ls -l</tt> (shown as "+" after permissions). |
|||
$ cd "$WORKSPACE" |
|||
== Extending Workspaces == |
|||
$ ws_extend myWs 100 # Extend by 100 days (same as ws_allocate -x) |
|||
Set workspace path in variable: |
|||
'''Note:''' Expiry is recalculated from ''now''. Extending too early reduces remaining time; extending near expiry gives maximum benefit. |
|||
$ DIR=$(ws_find my_workspace) |
|||
Group members can extend each other's workspaces: |
|||
'''View current ACLs:''' |
|||
$ ws_allocate -x -u alice myWs 100 # Requires workspace created with -G |
|||
$ getfacl "$DIR" |
|||
Each extension uses one of the 100 available extensions. Check remaining extensions with <tt>ws_list -l</tt>. |
|||
'''Grant read-only access to a user:''' |
|||
== Releasing Workspaces == |
|||
$ setfacl -Rm user:username:rX,default:user:username:rX "$DIR" |
|||
$ ws_release myWs |
|||
'''Grant read-write access to a user:''' |
|||
The workspace directory is immediately moved out of reach. The data is permanently deleted at the next nightly expirer run — <tt>ws_restore</tt> is possible until then. |
|||
$ setfacl -Rm user:username:rwX,default:user:username:rwX "$DIR" |
|||
<div style="border: 3px solid #dc3545; padding: 15px; background-color: #f8d7da; margin: 10px 0;"> |
|||
'''Grant read-only access to a group:''' |
|||
Do '''not''' rely on being able to restore a released workspace. If you have important data, archive it before releasing. |
|||
</div> |
|||
<tt>--delete-data</tt> skips even that window and deletes immediately ('''cannot be restored'''). Only use this if you are certain the data is no longer needed. |
|||
$ setfacl -Rm group:groupname:rX,default:group:groupname:rX "$DIR" |
|||
== Restoring Workspaces == |
|||
'''Remove all ACLs:''' |
|||
Restore workspaces that '''expired naturally''' (reached end of lifetime) within the 30-day grace period: |
|||
$ setfacl -Rb "$DIR" |
|||
$ ws_restore -l # (1) List restorable workspaces |
|||
==== Key Options ==== |
|||
$ ws_allocate restored 100 # (2) Create target workspace |
|||
$ ws_restore username-myWs-0 restored # (3) Restore |
|||
Use the '''full name''' from <tt>ws_restore -l</tt> (includes username prefix and timestamp), not the short name. |
|||
* <tt>-R</tt>: Apply to all files and subdirectories |
|||
* <tt>-m</tt>: Modify (add or change ACL entries) |
|||
* <tt>-b</tt>: Remove all ACL entries |
|||
* <tt>user:username:rwX</tt>: Set permissions for specific user |
|||
* <tt>group:groupname:rwX</tt>: Set permissions for specific group |
|||
* <tt>default:</tt> prefix: New files inherit these ACLs automatically |
|||
* <tt>r</tt>: Read permission |
|||
* <tt>w</tt>: Write permission |
|||
* <tt>X</tt>: Execute only on directories and already-executable files (capital X) |
|||
<div style="border: 3px solid #ffc107; padding: 12px; background-color: #fff3cd; margin: 10px 0;"> |
|||
'''Important:''' Always use the <tt>default:</tt> prefix to ensure new files get the correct permissions automatically. |
|||
'''Released workspaces''' (deleted with <tt>ws_release</tt>) can be restored with <tt>ws_restore</tt> until the next nightly expirer run — after that they are permanently deleted. |
|||
</div> |
|||
If the workspace is not listed, it has been '''permanently deleted''' — not recoverable by anyone. |
|||
==== Recommendation ==== |
|||
'''Always prefer <tt>ws_allocate -G</tt> or <tt>ws_share</tt> first.''' Use manual ACLs only for complex scenarios like: |
|||
* Sharing with specific users outside your group |
|||
* Different permissions for different users |
|||
* Fine-grained control not possible with <tt>-G</tt> or <tt>ws_share</tt> |
|||
=== Regular Unix Permissions === |
|||
{| class="wikitable" |
{| class="wikitable" |
||
|- |
|||
!style="width:40%" | Works on cluster |
|||
!style="width:10%" | bwUC 3.0 |
|||
!style="width:10%" | BinAC2 |
|||
!style="width:10%" | Helix |
|||
!style="width:10%" | JUSTUS 2 |
|||
!style="width:10%" | NEMO2 |
|||
|- |
|- |
||
!style="width:20%" | Option |
|||
|<tt>chmod</tt>/<tt>chgrp</tt> (Unix permissions) |
|||
!style="width:80%" | Description |
|||
|- |
|||
| style="text-align:center;" | |
|||
|<tt>-l</tt> |
|||
| style="text-align:center;" | |
|||
|List restorable workspaces |
|||
| style="text-align:center;" | |
|||
|- |
|||
|style="background-color:#90EE90; text-align:center;" | ✓ |
|||
|<tt>-u <username></tt> |
|||
|Restore another user's workspace (requires permission) |
|||
|} |
|} |
||
== Workspace Links == |
|||
Use standard Unix permissions with <tt>chmod</tt> and <tt>chgrp</tt> when you and your collaborators share a common Unix group. |
|||
Creates a directory of symlinks to all your workspaces for quick navigation: |
|||
'''CRITICAL WARNING:''' |
|||
* '''NEVER use chmod 777 or a+rwx''' - makes your data accessible to everyone on the system |
|||
* '''NEVER use chmod o+rwx or chmod o+w''' - allows anyone to modify or delete your files |
|||
* Only set group permissions (<tt>g+r</tt>, <tt>g+w</tt>) for your specific research group |
|||
$ ws_register ~/workspaces |
|||
==== Quick Examples ==== |
|||
$ ls ~/workspaces/ |
|||
myWs -> /work/classic/$USER-myWs |
|||
Re-run after creating new workspaces to keep the links up to date. |
|||
Set workspace path in variable: |
|||
== Sharing == |
|||
$ DIR=$(ws_find my_workspace) |
|||
<div style="border: 3px solid #dc3545; padding: 15px; background-color: #f8d7da; margin: 10px 0;"> |
|||
'''Read-only access for group:''' |
|||
'''NEVER use <tt>chmod 777</tt> / <tt>chmod o+rwx</tt>!''' |
|||
Making workspaces world-readable is a security policy violation — use the methods below. |
|||
</div> |
|||
=== Group workspaces (recommended) === |
|||
$ chgrp -R mygroup "$DIR" |
|||
$ chmod -R g+rX "$DIR" |
|||
$ ws_allocate -g myWs 100 # Group-readable (read-only for group) |
|||
'''Read-write access for group:''' |
|||
$ ws_allocate -G projectgroup myWs 100 # Group-writable (recommended for teams) |
|||
Set <tt>groupname</tt> in <tt>~/.ws_user.conf</tt> so you don't have to type it every time. |
|||
$ chgrp -R mygroup "$DIR" |
|||
$ chmod -R g+rswX "$DIR" |
|||
Benefits: team members can extend the workspace, <tt>ws_list -g</tt> shows it to everyone in the group, and new files automatically inherit group ownership. |
|||
==== Key Options ==== |
|||
=== Read-only sharing after creation === |
|||
* <tt>-R</tt>: Apply to all files and subdirectories |
|||
* <tt>g+r</tt>: Group read permission |
|||
* <tt>g+w</tt>: Group write permission |
|||
* <tt>g+x</tt>: Group execute permission |
|||
* <tt>X</tt>: Execute only on directories and already-executable files (capital X) |
|||
* <tt>s</tt>: Sticky bit - new files inherit group ownership |
|||
Share an existing workspace read-only with specific users outside your group: |
|||
'''Important:''' For read-write access, the sticky bit (<tt>s</tt>) ensures new files belong to the group, but you must re-run <tt>chmod</tt> to set permissions on new files. |
|||
$ ws_share share myWs alice bob # Grant read access |
|||
==== Recommendation ==== |
|||
$ ws_share unshare myWs alice # Remove access |
|||
$ ws_share list myWs # Show who has access |
|||
=== ACLs (per-user fine-grained) === |
|||
'''Always prefer <tt>ws_allocate -G groupname</tt> over manual Unix permissions.''' It handles everything automatically and correctly, including the sticky bit and proper permissions on all new files. |
|||
Use |
Use <tt>setfacl</tt> when <tt>-g</tt>/<tt>-G</tt> and <tt>ws_share</tt> don't cover your needs. |
||
$ DIR=$(ws_find my_workspace) |
|||
== Delete a Workspace == |
|||
$ setfacl -Rm user:alice:rX,default:user:alice:rX "$DIR" # Read-only for alice |
|||
{| class="wikitable" |
|||
$ setfacl -Rm user:bob:rwX,default:user:bob:rwX "$DIR" # Read-write for bob |
|||
|- |
|||
$ getfacl "$DIR" # View current ACLs |
|||
!style="width:40%" | Works on cluster |
|||
$ setfacl -Rb "$DIR" # Remove all ACLs |
|||
!style="width:10%" | bwUC 3.0 |
|||
!style="width:10%" | BinAC2 |
|||
!style="width:10%" | Helix |
|||
!style="width:10%" | JUSTUS 2 |
|||
!style="width:10%" | NEMO2 |
|||
|- |
|||
|<tt>ws_release --delete-data</tt> (immediate deletion) |
|||
|style="background-color:#90EE90; text-align:center;" | ✓ |
|||
| style="text-align:center;" | |
|||
| style="text-align:center;" | |
|||
| style="text-align:center;" | |
|||
|style="background-color:#90EE90; text-align:center;" | ✓ |
|||
|} |
|||
<tt>-R</tt> recursive, <tt>default:</tt> makes new files inherit the ACL, <tt>X</tt> execute only on dirs/executables. |
|||
To release a workspace, use: |
|||
== Workspace Handover == |
|||
$ ws_release myWs |
|||
When a team member leaves or transfers a project, their workspaces can be handed over without data loss. |
|||
'''Syntax:''' <tt>ws_release [options] workspace_name</tt> |
|||
=== Preparation (before someone leaves) === |
|||
'''What happens when you release:''' |
|||
* The workspace ID can be reused |
|||
* The directory is not accessible anymore |
|||
* The data is '''not deleted immediately''' - it is kept for a grace period |
|||
* The data can be recovered using <tt>ws_restore</tt> as long as it is not finally deleted |
|||
* The real deletion will probably take place during nighttime |
|||
<tt>-G groupname</tt> can only be set '''at creation time'''. Always create shared research data with it from the start: |
|||
'''Important Notes:''' |
|||
* Data in a released workspace can still account for quota usage |
|||
* If the data is limiting you, delete the data '''before''' releasing the workspace, or restore it, delete it, and release again |
|||
* '''Recommendation:''' If you need to free quota immediately, delete files with <tt>rm -rf</tt> before releasing |
|||
$ ws_allocate -G projectgroup -c "ML training data – contact alice" myWs 100 |
|||
=== Options === |
|||
This ensures: |
|||
{| class="wikitable" |
|||
* Group members can see the workspace with <tt>ws_list -g</tt> |
|||
|- |
|||
* Any group member can extend it: <tt>ws_allocate -x -u alice myWs 100</tt> |
|||
!style="width:30%" | Option |
|||
* Data remains accessible after the original owner's account is deactivated |
|||
!style="width:70%" | Description |
|||
|- |
|||
|<tt>-n <name></tt> |
|||
|Workspace name (alternative to positional argument) |
|||
|- |
|||
|<tt>-F <filesystem></tt> |
|||
|Specify filesystem where the workspace is located |
|||
|- |
|||
|<tt>--delete-data</tt> |
|||
|Delete all data immediately. '''WARNING: Workspace can NOT BE RECOVERED''' |
|||
|} |
|||
To ensure someone else receives expiry reminders, there are two options: |
|||
=== Immediate Deletion === |
|||
* Add their email to <tt>~/.ws_user.conf</tt> of the owner (or use <tt>-m email</tt> at allocate time): |
|||
The <tt>--delete-data</tt> flag immediately deletes all data: |
|||
<pre> |
|||
$ ws_release --delete-data myWs |
|||
mailaddress: alice@uni-freiburg.de,backup@uni-freiburg.de |
|||
</pre> |
|||
* Or actively take over the reminders as the new responsible person: |
|||
'''Warning:''' Deleted data from workspaces is permanently lost and cannot be recovered. |
|||
$ ws_allocate -r 7 -u alice -x myWs 0 # Redirect reminders to yourself |
|||
'''When to use:''' |
|||
* Use <tt>ws_release</tt> (without flag) when you might need to recover data |
|||
* Use <tt>ws_release --delete-data</tt> when you're certain you don't need the data and want to free quota immediately |
|||
== |
=== After the owner has left === |
||
If the workspace was created with <tt>-G groupname</tt>, a group member can keep it alive: |
|||
{| class="wikitable" |
|||
|- |
|||
!style="width:40%" | Works on cluster |
|||
!style="width:10%" | bwUC 3.0 |
|||
!style="width:10%" | BinAC2 |
|||
!style="width:10%" | Helix |
|||
!style="width:10%" | JUSTUS 2 |
|||
!style="width:10%" | NEMO2 |
|||
|- |
|||
|<tt>ws_restore</tt> |
|||
|style="background-color:#90EE90; text-align:center;" | ✓ |
|||
|style="background-color:#90EE90; text-align:center;" | ✓ |
|||
|style="background-color:#90EE90; text-align:center;" | ✓ |
|||
|style="background-color:#90EE90; text-align:center;" | ✓ |
|||
|style="background-color:#90EE90; text-align:center;" | ✓ |
|||
|} |
|||
$ ws_list -g # Find group workspaces |
|||
For a certain (system-specific) grace time following workspace expiration, a workspace can be restored. |
|||
$ ws_allocate -x -u formercolleague myWs 100 # Extend (while still restorable) |
|||
If the workspace has already expired, an authorized group member or administrator can restore it: |
|||
'''Syntax:''' <tt>ws_restore [options] workspace_name target_name | -l</tt> |
|||
$ ws_restore -u formercolleague -l # List their restorable workspaces |
|||
=== Restore Procedure === |
|||
$ ws_allocate newname 100 |
|||
$ ws_restore -u formercolleague formercolleague-myWs-0 newname |
|||
=== Workspaces without group access === |
|||
'''(1) Display restorable workspaces:''' |
|||
If the workspace was created without <tt>-g</tt>/<tt>-G</tt>, contact the HPC support team for assistance during the grace period (30 days after expiry). |
|||
$ ws_restore -l |
|||
== Reminders == |
|||
This will list all workspaces that can still be recovered. You can use <tt>-b</tt> or <tt>--brief</tt> to hide the unavailability date in the list. |
|||
Reminders are automatic. The notification goes to your identity provider email address. |
|||
'''(2) Create a new workspace as the target for the restore:''' |
|||
Customize reminder timing at workspace creation: |
|||
$ ws_allocate restored 60 |
|||
$ ws_allocate -r 7 myWs 100 # Reminder 7 days before expiry |
|||
'''(3) Restore the expired workspace:''' |
|||
Custom email address: |
|||
$ ws_restore <full_name_of_expired_workspace> restored |
|||
$ ws_allocate -m custom@example.com myWs 100 |
|||
'''Important:''' |
|||
* The expired workspace must be specified using the '''full name''' as printed by <tt>ws_restore -l</tt> (not as printed by <tt>ws_list</tt>!), including username prefix and timestamp suffix (otherwise it cannot be uniquely identified) |
|||
* The target workspace must be given with just its '''short name''' as listed by <tt>ws_list</tt>, without the username prefix |
|||
* '''<tt>ws_restore</tt> can only work on the same filesystem.''' Ensure the new workspace is on the same filesystem as the expired workspace. Use <tt>-F <filesystem></tt> flag if needed |
|||
Update reminder timing (or take over reminders) without extending: |
|||
Example: |
|||
$ ws_allocate -r 7 -x myWs 0 # Change timing only |
|||
$ ws_restore username-myWs-0 restored |
|||
$ ws_allocate -r 7 -u alice -x myWs 0 # Take over reminders for Alice's workspace |
|||
The last command is useful when taking responsibility for a colleague's workspace. |
|||
=== Options === |
|||
== Quotas & Limits == |
|||
{| class="wikitable" |
|||
|- |
|||
!style="width:30%" | Option |
|||
!style="width:70%" | Description |
|||
|- |
|||
|<tt>-l</tt>, <tt>--list</tt> |
|||
|List restorable workspaces. '''Use this first''' to see what can be recovered |
|||
|- |
|||
|<tt>-b</tt>, <tt>--brief</tt> |
|||
|Do not show unavailability date in list (used with <tt>-l</tt>) |
|||
|- |
|||
|<tt>-n <name></tt> |
|||
|Workspace name (alternative to positional argument) |
|||
|- |
|||
|<tt>-t <target></tt> |
|||
|Existing target workspace name (alternative to positional argument) |
|||
|- |
|||
|<tt>-F <filesystem></tt> |
|||
|Specify filesystem where the workspace is located |
|||
|- |
|||
|<tt>-u <username></tt> |
|||
|Username (for restoring other users' workspaces if permitted) |
|||
|} |
|||
=== If Workspace Cannot Be Restored === |
|||
If the workspace is not visible/restorable, it has been '''permanently deleted''' and cannot be restored, not even by system administrators. |
|||
'''Helix-specific - Workspace Snapshots:''' |
|||
On Helix, if the workspace can't be restored anymore using <tt>ws_restore</tt>, you can check the snapshots under: |
|||
/work/.snapshots/<timepoint>/ws/ |
|||
'''Important notes about snapshots:''' |
|||
* Snapshots are point-in-time copies of the workspace filesystem |
|||
* Changes that happened since the last snapshot was created are lost |
|||
* Browse available snapshot timepoints in <tt>/work/.snapshots/</tt> |
|||
* '''Caution:''' The Helix team tries to keep the latest snapshots, but they cannot guarantee that snapshots will be available at all times |
|||
* Snapshots are a last resort when <tt>ws_restore</tt> no longer works |
|||
'''How to use snapshots:''' |
|||
$ ls /work/.snapshots/ # List available snapshot timepoints |
|||
$ cd /work/.snapshots/2025-11-15_00.00.00/ws/ |
|||
$ ls # Find your old workspace directory |
|||
$ cp -r username-myWs-0 /path/to/active/workspace/ # Copy data to active workspace |
|||
Contact Helix support if you need assistance with snapshot recovery. |
|||
'''Please remember:''' Workspaces are intended solely for temporary work data, and there is '''no backup''' of data in the workspaces. |
|||
'''Recommendation:''' Email reminders are sent automatically. You can optionally customize reminder timing with <tt>-r</tt> option to be notified earlier, giving you time to extend the workspace or backup important data to appropriate permanent storage. |
|||
=== Cluster-Specific Information === |
|||
Retention periods for expired/released workspaces vary by cluster: |
|||
{| class="wikitable" |
{| class="wikitable" |
||
|- |
|- |
||
!style="width: |
!style="width:35%" | Parameter |
||
!style="width: |
!style="width:65%" | Value |
||
!style="width:35%" | Released Workspace Retention |
|||
|- |
|- |
||
|Default lifetime |
|||
|bwUniCluster 3.0 |
|||
|30 days |
|30 days |
||
|Until next night |
|||
|- |
|- |
||
|Maximum lifetime |
|||
|Helix |
|||
|100 days |
|||
|System-specific grace period |
|||
|System-specific grace period |
|||
|- |
|- |
||
|Maximum extensions |
|||
|JUSTUS 2 |
|||
|100 times |
|||
|System-specific grace period |
|||
|System-specific grace period |
|||
|- |
|- |
||
|Storage quota |
|||
|BinAC2 |
|||
|5 TiB per workspace |
|||
|System-specific grace period |
|||
|System-specific grace period |
|||
|- |
|- |
||
|Grace period (expired workspaces) |
|||
|NEMO2 |
|||
|30 days (recoverable with <tt>ws_restore</tt>) |
|||
|30 days |
|||
|Until next night |
|||
|} |
|||
== Cluster-Specific Workspace Limits == |
|||
Different clusters have different workspace policies. Below is an overview of typical settings: |
|||
{| class="wikitable" |
|||
|- |
|||
!style="width:15%" | Cluster |
|||
!style="width:15%" | Default Lifetime |
|||
!style="width:15%" | Max Lifetime |
|||
!style="width:15%" | Max Extensions |
|||
!style="width:20%" | User Quota |
|||
!style="width:20%" | Inode Quota |
|||
|- |
|- |
||
|Grace period (released workspaces) |
|||
|bwUniCluster 3.0 |
|||
|next nightly expirer run ('''not reliably recoverable''') |
|||
|1 day (typical) |
|||
|60 days (renewable 3x to 240 days total) |
|||
|3 times |
|||
|40 TiB |
|||
|20 million |
|||
|- |
|||
|JUSTUS 2 |
|||
|7 days |
|||
|90 days |
|||
|Unlimited |
|||
|20 TiB |
|||
|5 million |
|||
|- |
|||
|Helix |
|||
|N/A |
|||
|30 days |
|||
|10 times |
|||
|10 TiB |
|||
|No limit |
|||
|- |
|||
|BinAC2 |
|||
|N/A |
|||
|30 days |
|||
|5 times |
|||
|None |
|||
|None |
|||
|- |
|||
|NEMO2 |
|||
|30 days |
|||
|100 days |
|||
|100 times |
|||
|5 TiB per workspace |
|||
|No limit |
|||
|} |
|} |
||
Check quota: |
|||
'''Note:''' Check your specific cluster documentation for current quotas, as they may change. Use <tt>ws_list -l</tt> to see available filesystems and their properties on your cluster. |
|||
$ nemoquota # HOME + workspace quotas |
|||
== Checking Workspace Quotas == |
|||
$ df --si $(ws_find myWs) # Size of a specific workspace |
|||
Released workspaces count toward quota until the nightly cleanup runs. Use <tt>ws_release --delete-data</tt> for immediate relief ('''irreversible'''). |
|||
The command to check workspace quota usage varies by cluster and filesystem: |
|||
== Best Practices == |
|||
'''Lustre-based clusters (bwUniCluster 3.0, JUSTUS 2):''' |
|||
# Set up <tt>~/.ws_user.conf</tt> — defaults save time and prevent mistakes |
|||
$ lfs quota -uh $(whoami) /lustre/work # or appropriate workspace path |
|||
# Use <tt>-G groupname</tt> for research data — essential for handover and collaboration |
|||
$ lfs quota -uh $(whoami) /pfs/work9 # bwUniCluster 3.0 |
|||
# Create workspaces on the login node — use <tt>ws_find</tt> in job scripts, don't create inside jobs |
|||
# Monitor with <tt>ws_list -Rr</tt> — sort by remaining time to catch workspaces about to expire |
|||
# Archive before expiry — workspaces are not backed up |
|||
# Clean up finished workspaces — <tt>ws_release</tt> frees quota and reduces clutter |
|||
Single-node temporary files belong in <tt>$TMPDIR</tt>, not workspaces. |
|||
'''NEMO2 (Weka filesystem):''' |
|||
$ nemoquota # Shows HOME and workspace quotas |
|||
$ df --si $(ws_find workspace_name) # Check specific workspace |
|||
'''Helix (IBM Spectrum Scale):''' |
|||
$ workquotainfo # Shows workspace quota info |
|||
'''BinAC2:''' |
|||
* No quota limits enforced on workspaces |
|||
* Check available space with <tt>df</tt> command |
|||
'''General tip:''' Always check disk usage before large data operations to ensure sufficient space is available. |
|||
== Register Workspace Links == |
|||
The <tt>ws_register</tt> command creates or updates symbolic links to your workspaces in a directory of your choice. This provides a convenient way to access all your workspaces from a single location. |
|||
'''Syntax:''' <tt>ws_register [-h] [--version] [-F FILESYSTEM] directory</tt> |
|||
'''Usage:''' |
|||
$ ws_register ~/workspaces |
|||
This will create symbolic links to all your workspaces in the <tt>~/workspaces</tt> directory. |
|||
Example: |
|||
$ mkdir -p ~/my_workspaces |
|||
$ ws_register ~/my_workspaces |
|||
$ ls -l ~/my_workspaces |
|||
lrwxrwxrwx 1 user group 45 Nov 17 10:30 myWs -> /work/workspace/scratch/user-myWs-0 |
|||
lrwxrwxrwx 1 user group 48 Nov 17 10:30 project1 -> /work/workspace/scratch/user-project1-0 |
|||
=== Options === |
|||
{| class="wikitable" |
|||
|- |
|||
!style="width:30%" | Option |
|||
!style="width:70%" | Description |
|||
|- |
|||
|<tt>directory</tt> |
|||
|Directory in which links shall be created/updated (required positional argument) |
|||
|- |
|||
|<tt>-F <filesystem></tt>, <tt>--filesystem <filesystem></tt> |
|||
|Filesystem to search workspaces in. Only create links for workspaces on this filesystem |
|||
|- |
|||
|<tt>-h</tt>, <tt>--help</tt> |
|||
|Show help message |
|||
|- |
|||
|<tt>--version</tt> |
|||
|Show program's version number and exit |
|||
|} |
|||
'''When to use:''' |
|||
* '''Recommended''' if you work with multiple workspaces and want quick access |
|||
* Use in your <tt>~/.bashrc</tt> or login scripts to automatically update links at login |
|||
* Useful for organizing workspaces by project or purpose |
|||
'''Example in login script:''' |
|||
<pre> |
|||
# In ~/.bashrc |
|||
if command -v ws_register &> /dev/null; then |
|||
mkdir -p ~/workspaces |
|||
ws_register ~/workspaces 2>/dev/null |
|||
fi |
|||
</pre> |
|||
Latest revision as of 17:58, 12 May 2026
For basic daily usage see the main Workspaces guide.
Creating Workspaces
$ ws_allocate myWs 100
Returns the workspace path, e.g. /work/classic/$USER-myWs. Running the same command again is safe — it returns the existing workspace path.
Capture path in variable:
$ WORKSPACE=$(ws_allocate myWs 100) $ cd "$WORKSPACE"
Common options:
$ ws_allocate -g myWs 100 # Group-readable workspace $ ws_allocate -G projectgroup myWs 100 # Group-writable workspace $ ws_allocate -r 7 myWs 100 # Reminder 7 days before expiry $ ws_allocate -c "ML training data" myWs 100 # Add comment (shown in ws_list -l) $ ws_allocate -x myWs 100 # Extend existing workspace $ ws_allocate -x -u alice myWs 100 # Extend Alice's group workspace $ ws_allocate -r 7 -x myWs 0 # Update reminder only (no extension)
| Option | Description |
|---|---|
| -g | Group-readable workspace |
| -G <groupname> | Group-writable workspace. Set default in ~/.ws_user.conf |
| -m <email> | Custom email for reminders (overrides identity provider email) |
| -r <days> | Reminder n days before expiration |
| -c <comment> | Comment shown in ws_list -l |
| -x | Extend existing workspace |
| -u <username> | Target another user's workspace (requires -G) |
Using workspaces in batch jobs:
Create the workspace once on the login node, then use ws_find in the job script:
#!/bin/bash #SBATCH --job-name=my_job WORKSPACE=$(ws_find myProject) cd "$WORKSPACE" ./my_program --input input.dat --output results.dat
User Defaults: ~/.ws_user.conf
Set defaults so you never forget important options. The file is in YAML format:
duration: 100 reminder: 7 groupname: projectgroup
Important: The first line must be a setting, not a comment. Some versions interpret a leading # as an email address.
With the config above, ws_allocate myWs automatically creates a 100-day workspace with a 7-day reminder for the default group — no extra flags needed.
| Setting | Description |
|---|---|
| duration: | Default lifetime in days |
| reminder: | Days before expiration for reminder |
| groupname: | Default group for -G (see Sharing) |
| mail: | Override notification email (optional) |
Listing Workspaces
$ ws_list # All your workspaces $ ws_list -Rr # Sort by remaining time (soonest first) $ ws_list -g # Include group workspaces
Example output:
id: myWs workspace directory : /work/classic/$USER-myWs remaining time : 6 days 23 hours creation time : Thu Apr 17 09:23:41 2025 expiration time : Mon May 26 09:23:41 2025 available extensions : 98
| Option | Description |
|---|---|
| -l | Long listing (shows creation time, comment, extensions remaining) |
| -R | Show remaining time as human-readable |
| -r | Reverse sort order |
| -s | Sort by creation time |
| -g | Include group workspaces (not just owned) |
Finding Workspace Paths
Returns the full path — primarily useful in scripts:
$ ws_find myWs /work/classic/$USER-myWs
$ WORKSPACE=$(ws_find myWs) $ cd "$WORKSPACE"
Extending Workspaces
$ ws_extend myWs 100 # Extend by 100 days (same as ws_allocate -x)
Note: Expiry is recalculated from now. Extending too early reduces remaining time; extending near expiry gives maximum benefit.
Group members can extend each other's workspaces:
$ ws_allocate -x -u alice myWs 100 # Requires workspace created with -G
Each extension uses one of the 100 available extensions. Check remaining extensions with ws_list -l.
Releasing Workspaces
$ ws_release myWs
The workspace directory is immediately moved out of reach. The data is permanently deleted at the next nightly expirer run — ws_restore is possible until then.
Do not rely on being able to restore a released workspace. If you have important data, archive it before releasing.
--delete-data skips even that window and deletes immediately (cannot be restored). Only use this if you are certain the data is no longer needed.
Restoring Workspaces
Restore 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
Use the full name from ws_restore -l (includes username prefix and timestamp), not the short name.
Released workspaces (deleted with ws_release) can be restored with ws_restore until the next nightly expirer run — after that they are permanently deleted.
If the workspace is not listed, it has been permanently deleted — not recoverable by anyone.
| Option | Description |
|---|---|
| -l | List restorable workspaces |
| -u <username> | Restore another user's workspace (requires permission) |
Workspace Links
Creates a directory of symlinks to all your workspaces for quick navigation:
$ ws_register ~/workspaces $ ls ~/workspaces/ myWs -> /work/classic/$USER-myWs
Re-run after creating new workspaces to keep the links up to date.
Sharing
NEVER use chmod 777 / chmod o+rwx! Making workspaces world-readable is a security policy violation — use the methods below.
Group workspaces (recommended)
$ ws_allocate -g myWs 100 # Group-readable (read-only for group) $ ws_allocate -G projectgroup myWs 100 # Group-writable (recommended for teams)
Set groupname in ~/.ws_user.conf so you don't have to type it every time.
Benefits: team members can extend the workspace, ws_list -g shows it to everyone in the group, and new files automatically inherit group ownership.
Read-only sharing after creation
Share an existing workspace read-only with specific users outside your group:
$ ws_share share myWs alice bob # Grant read access $ ws_share unshare myWs alice # Remove access $ ws_share list myWs # Show who has access
ACLs (per-user fine-grained)
Use setfacl when -g/-G and ws_share don't cover your needs.
$ DIR=$(ws_find my_workspace)
$ setfacl -Rm user:alice:rX,default:user:alice:rX "$DIR" # Read-only for alice $ setfacl -Rm user:bob:rwX,default:user:bob:rwX "$DIR" # Read-write for bob $ getfacl "$DIR" # View current ACLs $ setfacl -Rb "$DIR" # Remove all ACLs
-R recursive, default: makes new files inherit the ACL, X execute only on dirs/executables.
Workspace Handover
When a team member leaves or transfers a project, their workspaces can be handed over without data loss.
Preparation (before someone leaves)
-G groupname can only be set at creation time. Always create shared research data with it from the start:
$ ws_allocate -G projectgroup -c "ML training data – contact alice" myWs 100
This ensures:
- Group members can see the workspace with ws_list -g
- Any group member can extend it: ws_allocate -x -u alice myWs 100
- Data remains accessible after the original owner's account is deactivated
To ensure someone else receives expiry reminders, there are two options:
- Add their email to ~/.ws_user.conf of the owner (or use -m email at allocate time):
mailaddress: alice@uni-freiburg.de,backup@uni-freiburg.de
- Or actively take over the reminders as the new responsible person:
$ ws_allocate -r 7 -u alice -x myWs 0 # Redirect reminders to yourself
After the owner has left
If the workspace was created with -G groupname, a group member can keep it alive:
$ ws_list -g # Find group workspaces $ ws_allocate -x -u formercolleague myWs 100 # Extend (while still restorable)
If the workspace has already expired, an authorized group member or administrator can restore it:
$ ws_restore -u formercolleague -l # List their restorable workspaces $ ws_allocate newname 100 $ ws_restore -u formercolleague formercolleague-myWs-0 newname
Workspaces without group access
If the workspace was created without -g/-G, contact the HPC support team for assistance during the grace period (30 days after expiry).
Reminders
Reminders are automatic. The notification goes to your identity provider email address.
Customize reminder timing at workspace creation:
$ ws_allocate -r 7 myWs 100 # Reminder 7 days before expiry
Custom email address:
$ ws_allocate -m custom@example.com myWs 100
Update reminder timing (or take over reminders) without extending:
$ ws_allocate -r 7 -x myWs 0 # Change timing only $ ws_allocate -r 7 -u alice -x myWs 0 # Take over reminders for Alice's workspace
The last command is useful when taking responsibility for a colleague's workspace.
Quotas & Limits
| Parameter | Value |
|---|---|
| Default lifetime | 30 days |
| Maximum lifetime | 100 days |
| Maximum extensions | 100 times |
| Storage quota | 5 TiB per workspace |
| Grace period (expired workspaces) | 30 days (recoverable with ws_restore) |
| Grace period (released workspaces) | next nightly expirer run (not reliably recoverable) |
Check quota:
$ nemoquota # HOME + workspace quotas $ df --si $(ws_find myWs) # Size of a specific workspace
Released workspaces count toward quota until the nightly cleanup runs. Use ws_release --delete-data for immediate relief (irreversible).
Best Practices
- Set up ~/.ws_user.conf — defaults save time and prevent mistakes
- Use -G groupname for research data — essential for handover and collaboration
- Create workspaces on the login node — use ws_find in job scripts, don't create inside jobs
- Monitor with ws_list -Rr — sort by remaining time to catch workspaces about to expire
- Archive before expiry — workspaces are not backed up
- Clean up finished workspaces — ws_release frees quota and reduces clutter
Single-node temporary files belong in $TMPDIR, not workspaces.