Workspaces/Advanced Features: Difference between revisions

From bwHPC Wiki
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
Tag: Reverted
Line 1: Line 1:
<div style="border: 3px solid #ffc107; padding: 15px; background-color: #fff3cd; margin: 10px 0;">
This document covers advanced features and detailed configuration options for the HPC workspace tools. For basic daily usage, see the main [[Workspaces]] guide.
'''Note:''' This is a new Workspaces page. The old wiki can be found here: [[Workspace]].
</div>

'''Workspace tools''' provide temporary scratch spaces called '''workspaces''' for your calculations on central file storage. They are meant to keep data for a limited time – but usually longer than the time of a single job run.

<div style="border: 3px solid #dc3545; padding: 15px; background-color: #f8d7da; margin: 10px 0;">
'''Important - Read Before Using Workspaces:'''

* '''No Backup:''' Data in workspaces is '''not backed up''' and will be '''automatically deleted''' after expiration
* '''Time-limited:''' Every workspace has a limited lifetime (typically 30-100 days depending on cluster), see the [[Workspaces/Advanced_Features#Cluster-Specific_Workspace_Limits|Cluster-Specific Workspace Limits]])
* '''Automatic Reminders:''' You will receive email notifications before expiration
* '''Backup Important Data:''' Copy important results to permanent storage before expiration (check your cluster/site policies for backup locations)
</div>

'''For detailed information''' about advanced features, configuration options, and less frequently used commands, see the '''[[Workspaces/Advanced Features]]''' guide.

== Command Overview ==

The workspace tools consist of several commands:

* <tt>ws_allocate</tt> - Create or extend a workspace
* <tt>ws_list</tt> - List all your workspaces
* <tt>ws_find</tt> - Find the path to a workspace
* <tt>ws_extend</tt> - Extend the lifetime of a workspace
* <tt>ws_release</tt> - Release (delete) a workspace
* <tt>ws_restore</tt> - Restore an expired or released workspace
* <tt>ws_register</tt> - Create symbolic links to workspaces

All commands support <tt>-h</tt> or <tt>--help</tt> to show detailed usage information.


== Quick Start - Most Common Commands ==
== Almost Complete Command Reference ==


{| class="wikitable"
{| class="wikitable"
Line 10: Line 39:
|Create workspace for 30 days
|Create workspace for 30 days
|<tt>ws_allocate myWs 30</tt>
|<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
|Create group-writable workspace
|<tt>ws_allocate -G groupname myWs 30</tt>
|<tt>ws_allocate -G groupname myWs 30</tt>
|-
|Create on specific filesystem
|<tt>ws_allocate -F filesystem myWs 30</tt>
|-
|-
|List all your workspaces
|List all your workspaces
|<tt>ws_list</tt>
|<tt>ws_list</tt>
|-
|-
|Check which expire soon
|List by remaining time
|<tt>ws_list -R</tt>
|<tt>ws_list -Rr</tt>
|-
|-
|Find workspace path (for scripts)
|List available filesystems
|<tt>ws_list -l</tt> or <tt>ws_find -l</tt>
|-
|Find workspace path
|<tt>ws_find myWs</tt>
|<tt>ws_find myWs</tt>
|-
|-
|Extend workspace by 40 days
|Extend workspace by 30 days
|<tt>ws_extend myWs 40</tt> or <tt>ws_allocate -x myWs 40</tt>
|<tt>ws_extend myWs 30</tt>
|-
|-
|Delete/release workspace
|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>
|<tt>ws_release myWs</tt>
|-
|-
|Restore released workspace
|List restorable workspaces
|<tt>ws_restore -l</tt>
|<tt>ws_restore -l</tt> then <tt>ws_restore oldname newname</tt>
|-
|Register workspace links
|<tt>ws_register ~/workspaces</tt>
|}
|}


== Create Workspace ==
== Multiple Filesystem Locations ==


To create a workspace you need to specify a '''name''' and '''lifetime''' in days:
{| 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>-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;" | ✗
|}


'''Basic usage:'''
Some clusters offer multiple filesystem locations for workspaces with different characteristics:


$ ws_allocate myWs 30 # Create workspace for 30 days
'''bwUniCluster 3.0:'''
* 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 variations:'''
'''Example creating workspace on flash filesystem:'''


$ ws_allocate -G groupname myWs 30 # Create group-writable workspace (recommended for teams)
$ ws_allocate -F ffuc myworkspace 60
$ ws_allocate -g myWs 30 # Create group-readable workspace
$ ws_allocate -F ffuc myWs 30 # bwUniCluster 3.0: Use flash filesystem


This returns:
Use <tt>ws_list -l</tt> or <tt>ws_find -l</tt> to see available filesystem locations on your cluster.

== ws_allocate - Create and Extend 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>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.
Workspace created. Duration is 720 hours.
Line 119: Line 82:
/work/workspace/scratch/username-myWs-0
/work/workspace/scratch/username-myWs-0


'''Important:''' Creating a workspace a second time with the same command is safe - it always returns the same path.
The command returns the path to the new directory, which can be captured in a variable:


'''Capture the path in a variable:'''
$ SCRDIR=$(ws_allocate myWs 10)


$ WORKSPACE=$(ws_allocate myWs 30)
'''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.
$ cd $WORKSPACE


'''For all options and advanced usage,''' see the [[Workspaces/Advanced_Features#ws_allocate_-_Create_and_Extend_Workspaces|Advanced Features guide]].
=== All Options and When to Use Them ===


== List Your Workspaces ==
{| class="wikitable"
|-
!style="width:20%" | Option
!style="width:40%" | 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>
|Create a 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>
|Create a group-writable workspace with sticky bit
|'''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 <mailaddress></tt>
|Set email address for reminders
|'''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>
|Set reminder to be sent 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>-x</tt>
|Extend an existing workspace
|Use when you need more time. Each extension consumes one of the available extensions
|-
|<tt>-u <username></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>
|}


'''Basic usage:'''
=== Duration Settings ===


$ ws_list # List all your workspaces
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.


Shows:
For more information read the program's help: <tt>$ ws_allocate -h</tt> or <tt>man ws_allocate</tt>
* Workspace ID
* Workspace location
* Available extensions
* Creation date and remaining time


'''Common variations:'''
== ws_list - List Workspaces ==


$ ws_list -Rr # Sort by remaining time (see what expires soon)
Beyond the basic options shown in the main [[Workspaces]] guide, <tt>ws_list</tt> supports additional sorting and filtering:
$ ws_list -s # Short format (only names, good for scripts)
$ ws_list -g # List group workspaces


'''Note:''' To list expired workspaces that can be restored, see [[#Restore_Workspace|Restore Workspace]].
'''Sorting options:'''
* <tt>-N</tt> - Sort by name (alphabetical)
* <tt>-C</tt> - Sort by creation date
* <tt>-R</tt> - Sort by remaining time (see what expires soon)
* <tt>-r</tt> - Reverse sort order


'''For all options,''' see the [[Workspaces/Advanced_Features#ws_list_-_List_Workspaces|Advanced Features guide]].
'''Display format options:'''
* <tt>-s</tt> - Short format (only names, good for scripts)
* <tt>-t</tt> - Terse format
* <tt>-v</tt> - Verbose format with all metadata


== Extend Workspace Lifetime ==
'''Filtering options:'''
* <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


Extend a workspace before it expires:
'''Example listing group workspaces:'''

$ ws_list -g

This shows all workspaces that were created with <tt>-g</tt> or <tt>-G</tt> flags by members of your group.

'''Note:''' To list expired workspaces that can be restored, use <tt>ws_restore -l</tt>. See [[#ws_restore_-_Restore_Expired_Workspace|ws_restore]] for details.

For more information: <tt>$ ws_list -h</tt> or <tt>man ws_list</tt>

== ws_find - Find Workspace Path ==

<tt>ws_find</tt> returns the full path to a workspace, useful for scripts and automation.


'''Basic usage:'''
'''Basic usage:'''


$ ws_extend myWs 30 # Extend by 30 days from now
$ ws_find myWs


'''Options:'''
'''Alternative commands:'''
* <tt>-F <filesystem></tt> - Search workspace on specific filesystem
* <tt>-l</tt> - List valid filesystem names


$ ws_allocate -x myWs 30 # Same as ws_extend
'''Example in scripts:'''


'''Note:''' Each extension consumes one of your available extensions (see the [[Workspaces/Advanced_Features#Cluster-Specific_Workspace_Limits|Cluster-Specific Workspace Limits]]).
$ WORKSPACE=$(ws_find myProject)
$ cd "$WORKSPACE"


'''For all options,''' see the [[Workspaces/Advanced_Features#ws_extend_-_Extend_Workspace_Lifetime|Advanced Features guide]].
For more information: <tt>$ ws_find -h</tt> or <tt>man ws_find</tt>


== ws_extend - Extend Workspace Lifetime ==
== Release (Delete) Workspace ==


When you no longer need a workspace:
Beyond the basic extension shown in the main [[Workspaces]] guide:


'''Basic usage:'''
* <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


$ ws_release myWs # Release workspace (recoverable during grace period)
'''Group workspace extensions:'''


'''What happens:'''
Group members can extend group-writable workspaces (requires group write access <tt>ws_allocate -G</tt>):
* Workspace becomes inaccessible immediately
* Data is kept for a short grace period (usually until next cleanup run) and can be restored with <tt>ws_restore</tt>
* Released data may still count toward quota until final deletion


'''For all options,''' see the [[Workspaces/Advanced_Features#ws_release_-_Release_.28Delete.29_Workspace|Advanced Features guide]].
$ ws_allocate -x -u <username> <workspace_id> <days>


== Restore Workspace ==
Replace <tt><username></tt> with the workspace owner's username. This is useful when the workspace owner is unavailable and the workspace needs to be extended.

For more information: <tt>$ ws_extend -h</tt> or <tt>man ws_extend</tt>

== Getting Reminders ==


{| class="wikitable"
{| class="wikitable"
Line 258: Line 155:
!style="width:10%" | NEMO2
!style="width:10%" | NEMO2
|-
|-
|<tt>ws_restore</tt>
|Email reminders
|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;" | ✓
Line 264: Line 161:
|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>ws_send_ical</tt> (calendar reminders)
|style="background-color:#90EE90; text-align:center;" | ✓
|style="background-color:#FFB6C1; text-align:center;" | ✗
|style="background-color:#90EE90; text-align:center;" | ✓
|style="background-color:#FFB6C1; text-align:center;" | ✗
|style="background-color:#FFB6C1; text-align:center;" | ✗
|}
|}


If you released a workspace by accident or need to recover an expired one, you can restore it within a grace period:
'''Email reminders:''' Sent automatically using email addresses from your identity provider. You can customize the reminder timing with <tt>-r <days></tt>:

$ ws_allocate -r 7 myWs 30 # Reminder 7 days before expiry
$ ws_allocate -r 3 -m custom@example.com myWs 30 # Custom timing and different email address

'''Update reminder only''' (without extending workspace):


'''Basic workflow:'''
$ ws_allocate -r <days> -x <workspace> 0 # Update reminder time
$ ws_allocate -r <days> -u <username> -x <workspace> 0 # Update reminder time and take over
# another user's workspace reminders


$ ws_restore -l # (1) List restorable workspaces
This is useful when you want to change the reminder timing without extending the workspace lifetime, or when taking over responsibility for reminders on a colleague's workspace.
$ ws_allocate restored 60 # (2) Create a new target workspace
$ ws_restore username-myWs-0 restored # (3) Restore the expired workspace


'''Note:''' Use the '''full name''' from <tt>ws_restore -l</tt> (including username and timestamp), not the short name from <tt>ws_list</tt>.
'''Calendar reminder''' (bwUniCluster 3.0, Helix):


'''For detailed restore options,''' see the [[Workspaces/Advanced_Features#ws_restore_-_Restore_Expired_Workspace|Advanced Features guide]].
$ ws_send_ical <workspace> <email>


== Work with Groups (Share Workspaces) ==
=== ~/.ws_user.conf Configuration File ===

{| 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_user.conf</tt> configuration file
|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;" | ✓
|}

You can set defaults in <tt>~/.ws_user.conf</tt> (YAML format) to avoid typing the same options repeatedly:

<pre>
duration: 30 # Default workspace lifetime (first line must not start with #!)
reminder: 5 # Days before expiration to send reminder
groupname: projectgroup # Default group for -G option (e.g., bw11a000)
# mail: custom@example.com # Optional - only to override email from identity provider
</pre>

'''Important:''' Some versions mistakenly interpret a leading <tt>#</tt> comment as email. '''First line must be a setting''', not a comment. Inline comments are fine.

'''Benefits:'''
* Simplifies commands: <tt>ws_allocate myWs</tt> instead of <tt>ws_allocate -r 5 -G groupname myWs 30</tt>
* Ensures consistent settings across all operations
* Automatic group collaboration 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"
{| class="wikitable"
Line 360: Line 187:
|-
|-
|<tt>-g</tt> option (group-readable)
|<tt>-g</tt> option (group-readable)
|style="text-align:center;" |
|style="text-align:center;" |
|style="text-align:center;" |
|style="text-align:center;" |
|style="background-color:#90EE90; text-align:center;" | ✓
|-
|<tt>-G</tt> option (group-writable)
|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>ws_share</tt> command (ACL-based)
| style="text-align:center;" |
| style="text-align:center;" |
| style="text-align:center;" |
| style="text-align:center;" |
Line 412: Line 192:
| style="text-align:center;" |
| style="text-align:center;" |
|style="background-color:#90EE90; 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>setfacl</tt>/<tt>getfacl</tt> (ACLs)
|<tt>-G</tt> option (group-writable)
| style="text-align:center;" |
| style="text-align:center;" |
| style="text-align:center;" |
| style="text-align:center;" |
Line 459: Line 201:
|}
|}


Working with team members is simple using group workspaces:
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.


=== Create Group Workspace ===
'''Note:''' ACL support varies by filesystem. Not all clusters support ACLs on workspace filesystems. If ACL commands fail, use regular Unix permissions instead.


'''Group-readable workspace''' (team can read):
'''Key advantages:'''
* Share with specific users (not just groups)
* Default ACLs - new files automatically inherit permissions
* More flexible than Unix permissions


$ ws_allocate -g myWs 30
'''Note:''' ACLs take precedence over standard Unix permissions. View ACLs with <tt>ls -l</tt> (shown as "+" after permissions).


'''Group-writable workspace''' (team can read and write, recommended):
==== Quick Examples ====


$ ws_allocate -G projectgroup myWs 30
Set workspace path in variable:


Replace <tt>projectgroup</tt> with your actual group name (e.g., <tt>bw11a000</tt>).
$ DIR=$(ws_find my_workspace)


'''Tip:''' Set your default group in <tt>~/.ws_user.conf</tt> to avoid typing it every time:
'''View current ACLs:'''

$ getfacl "$DIR"

'''Important note on syntax:''' In all commands below, <tt>user:</tt> and <tt>group:</tt> are <tt>setfacl</tt> keywords. Replace <tt>username</tt> with the actual user login name (e.g., <tt>alice</tt>, <tt>jdoe</tt>) and <tt>groupname</tt> with the actual Unix group name (e.g., <tt>bw11a000</tt>).

'''Grant read-only access to a user:'''

$ setfacl -Rm user:username:rX,default:user:username:rX "$DIR"
# Example with actual username:
$ setfacl -Rm user:alice:rX,default:user:alice:rX "$DIR"

'''Grant read-write access to a user:'''

$ setfacl -Rm user:username:rwX,default:user:username:rwX "$DIR"
# Example with actual username:
$ setfacl -Rm user:jdoe:rwX,default:user:jdoe:rwX "$DIR"

'''Grant read-only access to a group:'''

$ setfacl -Rm group:groupname:rX,default:group:groupname:rX "$DIR"
# Example with actual groupname:
$ setfacl -Rm group:bw11a000:rX,default:group:bw11a000:rX "$DIR"

'''Remove all ACLs:'''

$ setfacl -Rb "$DIR"

==== Key Options ====

* <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 (replace <tt>username</tt> with actual login)
* <tt>group:groupname:rwX</tt>: Set permissions for specific group (replace <tt>groupname</tt> with actual 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)

'''Important:''' Always use the <tt>default:</tt> prefix to ensure new files get the correct permissions automatically.

==== 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"
|-
!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>chmod</tt>/<tt>chgrp</tt> (Unix permissions)
|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;" | ✓
|}

Use standard Unix permissions with <tt>chmod</tt> and <tt>chgrp</tt> when you and your collaborators share a common Unix group.

'''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

==== Quick Examples ====

Set workspace path in variable:

$ DIR=$(ws_find my_workspace)

'''Read-only access for group:'''

$ chgrp -R mygroup "$DIR"
$ chmod -R g+rX "$DIR"

'''Read-write access for group:'''

$ chgrp -R mygroup "$DIR"
$ chmod -R g+rswX "$DIR"

==== Key Options ====

* <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>: Setgid bit (set-group-ID) - new files inherit the directory's group ownership

'''Important:''' The setgid bit (<tt>g+s</tt>) ensures new files belong to the correct group, but their permissions depend on your <tt>umask</tt>. With the default umask (<tt>0022</tt>), new files will NOT be group-writable automatically. You must either:
* Set <tt>umask 0002</tt> in your shell so new files are group-writable by default, OR
* Manually run <tt>chmod g+w</tt> on new files, OR
* Use ACLs with <tt>default:</tt> entries (which override umask and handle permissions automatically)

==== Recommendation ====

'''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 manual <tt>chmod</tt>/<tt>chgrp</tt> only when <tt>-G</tt> is not available on your cluster or for fixing permissions on existing data.

== ws_release - Release (Delete) Workspace ==

Release a workspace when you no longer need it:

'''Basic usage:'''

$ ws_release myWs

'''Syntax:''' <tt>ws_release [options] workspace_name</tt>

'''What happens when you release:'''
* The workspace ID can be reused immediately
* The directory becomes inaccessible to the user
* The data is '''not deleted immediately''' - it is moved to a deleted area
* '''Released workspaces:''' Can be recovered using <tt>ws_restore</tt> for a short grace period (typically 1 hour after release)
* '''Expired workspaces:''' Can be recovered for a longer period (system-dependent, typically 7-30 days after expiration, configured via <tt>keeptime</tt> in <tt>/etc/ws.conf</tt>)
* Final deletion happens automatically during cleanup runs (usually nighttime)
* '''Important:''' Released workspace data may still count toward your quota until final deletion occurs

=== Options ===

{| class="wikitable"
|-
!style="width:30%" | Option
!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'''
|}

=== Immediate Deletion (Free Quota Instantly) ===

{| 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_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;" | ✓
|}

If you need to free quota immediately instead of waiting for the grace period, you have two options:

'''Option 1: Use --delete-data flag''' (recommended if available on your cluster):

$ ws_release --delete-data myWs

'''Availability:''' Check if this flag is available on your cluster with <tt>ws_release -h</tt>.

'''Option 2: Manual deletion before release''' (works on all clusters):

See the section on [[#Using_rm_for_Manual_Deletion|using rm for manual deletion]] below for the safe method.

'''CRITICAL WARNING:''' Both methods permanently delete data that '''cannot be recovered''', even by system administrators.

'''When to use immediate deletion:'''
* ✓ You're certain you don't need the data anymore
* ✓ You've already backed up important results to permanent storage
* ✓ You're hitting quota limits and need space immediately
* ✗ Don't use if there's any chance you might need the data
* ✗ Don't use if you haven't verified your backup worked

'''Best practice:''' Use regular <tt>ws_release myWs</tt> (without immediate deletion) as your default. Only use immediate deletion when you're absolutely certain and need immediate quota relief.

=== Using rm for Manual Deletion ===

If <tt>ws_release --delete-data</tt> is not available on your cluster, you can manually delete data before releasing:

$ rm -rf -- "$(ws_find myWs)"
$ ws_release myWs

'''Why this is safe:'''
* <tt>--</tt> prevents path from being interpreted as option (even if it starts with <tt>-</tt>)
* Quotes around <tt>$(ws_find myWs)</tt> handle paths with spaces safely
* If <tt>ws_find</tt> fails or returns empty, <tt>rm</tt> fails with "missing operand" (no deletion occurs)
* Direct and simple - no complex patterns or subshells needed

== ws_restore - Restore Expired Workspace ==

{| 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;" | ✓
|}

For a certain (system-specific) grace time following workspace expiration, a workspace can be restored.

'''Syntax:''' <tt>ws_restore [options] workspace_name target_name | -l</tt>

=== Restore Procedure ===

'''(1) Display restorable workspaces:'''

$ ws_restore -l

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.

'''(2) Create a new workspace as the target for the restore:'''

$ ws_allocate restored 60

'''(3) Restore the expired workspace:'''

$ ws_restore <full_name_of_expired_workspace> restored

'''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

Example:

$ ws_restore username-myWs-0 restored

=== Options ===

{| 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 ===

Grace periods for expired/released workspaces vary by cluster and are configured via the <tt>keeptime</tt> parameter in <tt>/etc/ws.conf</tt>:

{| class="wikitable"
|-
!style="width:30%" | Cluster
!style="width:35%" | Expired Workspace Retention (<tt>keeptime</tt>)
!style="width:35%" | Released Workspace Grace Period
|-
|bwUniCluster 3.0
|30 days
|~1 hour
|-
|Helix
|System-specific (check with support)
|~1 hour
|-
|JUSTUS 2
|System-specific (check with support)
|~1 hour
|-
|BinAC2
|System-specific (check with support)
|~1 hour
|-
|NEMO2
|30 days
|~1 hour
|}

'''Note:'''
* '''Expired workspaces''' (reached end of lifetime) are kept for <tt>keeptime</tt> days configured in <tt>/etc/ws.conf</tt>
* '''Released workspaces''' (via <tt>ws_release</tt>) are deleted faster - typically within 1 hour
* '''Actual deletion''' happens during automated cleanup runs, typically during nighttime
* This allows users to recover accidentally released workspaces quickly, while giving more time for expired workspaces

== Cluster-Specific Workspace Limits ==

Different clusters have different workspace policies configured in <tt>/etc/ws.conf</tt>. 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
|-
|bwUniCluster 3.0
|1 day
|60 days
|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
|None
|-
|BinAC2
|N/A
|30 days
|5 times
|None
|None
|-
|NEMO2
|30 days
|100 days
|100 times
|5 TiB per workspace
|None
|}

'''Configuration parameters in <tt>/etc/ws.conf</tt>:'''
* <tt>duration</tt> - Maximum lifetime in days
* <tt>maxextensions</tt> - Number of times a workspace can be extended
* <tt>keeptime</tt> - Days to keep expired workspaces before final deletion (typically 7-30 days)
* Released workspaces have a shorter grace period (~1 hour) regardless of <tt>keeptime</tt>

'''Note:''' Check your specific cluster documentation for current quotas and settings, as they may change. Use <tt>ws_list -l</tt> to see available filesystems and their properties on your cluster.

== Checking Workspace Quotas ==

The command to check workspace quota usage varies by cluster and filesystem:

'''Lustre-based clusters (bwUniCluster 3.0, JUSTUS 2):'''

$ lfs quota -uh $(whoami) /lustre/work # or appropriate workspace path
$ lfs quota -uh $(whoami) /pfs/work9 # bwUniCluster 3.0

'''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.

== ws_register - 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. The command creates subdirectories for each filesystem (e.g., <tt>scratch/</tt>) and places workspace links inside them.

Example:

$ mkdir -p ~/my_workspaces
$ ws_register ~/my_workspaces
$ ls -l ~/my_workspaces/scratch/
lrwxrwxrwx 1 user group 45 Nov 17 10:30 user-myWs -> /work/workspace/scratch/user-myWs-0
lrwxrwxrwx 1 user group 48 Nov 17 10:30 user-project1 -> /work/workspace/scratch/user-project1-0

'''Note:''' Links use the full workspace names (including username prefix), organized by filesystem subdirectory.

=== 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>
<pre>
groupname: projectgroup
# In ~/.bashrc or ~/.profile
# Only run in interactive shells to avoid issues with scp, rsync, etc.
if [ -t 0 ] && [ -z "$SSH_ORIGINAL_COMMAND" ] && command -v ws_register >/dev/null 2>&1; then
mkdir -p ~/workspaces >/dev/null 2>&1
ws_register ~/workspaces >/dev/null 2>&1
fi
</pre>
</pre>


Then you only need: <tt>ws_allocate myWs 30</tt>
== Using Workspaces in Batch Jobs ==


=== List Group Workspaces ===
'''Recommended approach:''' Create your workspace manually before submitting jobs, then reference it in your job scripts using <tt>ws_find</tt>.


See all workspaces from your group:
'''(1) Create workspace once (on login node):'''


$ ws_allocate myProject 60
$ ws_list -g

'''(2) Use in job scripts with ws_find:'''

<pre>
#!/bin/bash
#SBATCH --job-name=my_job
#SBATCH --time=24:00:00

# Find existing workspace
WORKSPACE=$(ws_find myProject)

# Change to workspace
cd $WORKSPACE

# Your computation here
./my_program --input input.dat --output results.dat
</pre>

'''Warning:''' Avoid using <tt>ws_allocate</tt> directly in job scripts that run frequently. While <tt>ws_allocate</tt> is safe to call multiple times on the same workspace name (it returns the existing workspace), you should not create too many workspaces unnecessarily. Create workspaces manually when needed, then use <tt>ws_find</tt> in your job scripts to locate them.

== Best Practices and Recommendations ==

=== For All Users ===

# '''Set up ~/.ws_user.conf''' - Configure default reminder timing, duration, and groupname to avoid typing them repeatedly (see [[Workspaces/Advanced_Features#.7E.2F.ws_user.conf_Configuration_File|configuration guide]])
# '''Email reminders are automatic''' - Notifications are sent automatically using your identity provider email; only use <tt>-r</tt> to customize reminder timing if needed
# '''Custom email only if needed''' - Only use <tt>-m</tt> option to override the email address from your identity provider
# '''Use ws_register''' - Create symbolic links to your workspaces in a convenient directory (see [[Workspaces/Advanced_Features#ws_register_-_Register_Workspace_Links|ws_register guide]])
# '''Create workspaces manually''' - Create workspaces on the login node before submitting jobs, then use <tt>ws_find</tt> in your job scripts (see [[#Using_Workspaces_in_Batch_Jobs|Using Workspaces in Batch Jobs]])
# '''Track your workspaces''' - Regularly run <tt>ws_list -R</tt> to see which workspaces will expire soon
# '''Backup important data''' - Workspaces are temporary and not backed up - copy results to appropriate permanent storage (check your cluster/site policies for backup locations)
# '''Clean up regularly''' - Release workspaces you no longer need to keep filesystems organized


This shows workspaces that were created with <tt>-g</tt> or <tt>-G</tt> by anyone in your group.
=== For Short-term Jobs (hours to days) ===


=== Extend Group Workspace ===
# Use default or shorter durations
# Consider using a single workspace for a series of related jobs
# Use <tt>ws_find</tt> in job scripts to locate the workspace (see [[#Using_Workspaces_in_Batch_Jobs|Using Workspaces in Batch Jobs]])
# Copy results to permanent storage when jobs complete
# Release workspace when no longer needed (see [[#Release_.28Delete.29_Workspace|Release Workspace]])


Anyone in the group can extend a group-writable workspace (<tt>-G</tt>):
=== For Long-term Campaigns (weeks to months) ===


$ ws_extend myWs 30 # If you created it
# Request maximum allowed duration (see [[Workspaces/Advanced_Features#Cluster-Specific_Workspace_Limits|Cluster-Specific Workspace Limits]])
$ ws_allocate -x -u username myWs 30 # If colleague created it
# Email reminders are sent automatically; optionally customize reminder timing with <tt>-r</tt> option
# Use <tt>ws_list -R</tt> regularly to monitor remaining time (see [[#List_Your_Workspaces|List Your Workspaces]])
# Plan data archival to appropriate permanent storage before expiration (check cluster/site policies)


Replace <tt>username</tt> with the workspace owner's username. This is useful when they're unavailable.
=== For Collaborative Work ===


=== Manage Reminders for Group Workspace ===
# Use <tt>ws_allocate -G groupname</tt> for shared write access (see [[#Create_Group_Workspace|Create Group Workspace]])
# Set <tt>groupname</tt> in <tt>~/.ws_user.conf</tt> if you always work with the same group (see [[Workspaces/Advanced_Features#.7E.2F.ws_user.conf_Configuration_File|configuration guide]])
# Use <tt>ws_allocate -g</tt> for read-only sharing within group
# Use <tt>ws_list -g</tt> to see all group workspaces (see [[#List_Group_Workspaces|List Group Workspaces]])
# Team members can extend group workspaces (see [[#Extend_Group_Workspace|Extend Group Workspace]])
# Take over reminder responsibility when colleague is unavailable (see [[#Manage_Reminders_for_Group_Workspace|Manage Reminders]])
# Document the workspace location for your team members
# For advanced sharing scenarios (ACL-based, ws_share), see the [[Workspaces/Advanced_Features#Cooperative_Usage_.28Group_Workspaces_and_Sharing.29|Advanced Features guide]]


You can update reminder settings and take over responsibility for reminders on a colleague's workspace:
=== For Managing Multiple Filesystems ===


$ ws_allocate -r 7 -u username -x myWs 0 # Update reminder time and take over
# '''Note:''' Most clusters have only one default filesystem - the <tt>-F</tt> option is rarely needed
# another user's workspace reminders
# Use <tt>ws_list -l</tt> first to check if multiple filesystems are available on your cluster
# Use <tt>-F</tt> option only if you need specific filesystem for performance or capacity needs (see [[Workspaces/Advanced_Features#Multiple_Filesystem_Locations|filesystem options]])
# '''bwUniCluster 3.0 filesystems:'''
#* '''Default Lustre filesystem:''' Standard workspace location, best for large files and sequential I/O
#* '''Flash filesystem (ffuc):''' SSD-based storage for KIT/HoreKa users, shared between bwUniCluster 3.0 and HoreKa
#* Use flash filesystem for workloads with many small files, random I/O, AI/ML training, or compilation
#* Balance load: use <tt>-F ffuc</tt> when appropriate to reduce load on default filesystem
# '''General guidelines:'''
#* Flash-based filesystems (SSD/NVMe): Use for many small files, low-latency requirements, random I/O
#* Standard Lustre/parallel filesystems: Best for large files and sequential I/O patterns


This changes the reminder timing to 7 days before expiration and redirects reminder emails to you instead of the original creator. Useful when you're taking over responsibility for a shared workspace.
=== For Different Data Types ===


=== Why Use Group Workspaces? ===
# '''Large sequential I/O:''' Use standard workspace filesystem (Lustre best for very large files, Weka excellent for both large and small)
# '''Many small files or random access:''' Use flash-based workspace filesystem like Weka (NEMO2) or bwUniCluster ffuc, or stage to <tt>$TMPDIR</tt>
# '''Data read multiple times on single node:''' Copy to <tt>$TMPDIR</tt> at job start for best performance
# '''Temporary data for single node:''' Always use <tt>$TMPDIR</tt>, not workspaces
# '''Multi-node temporary data:''' Use workspaces (not suitable for <tt>$TMPDIR</tt>)
# '''AI/ML training data:''' Use Weka (NEMO2) or flash filesystems for best performance, or stage to <tt>$TMPDIR</tt> for repeated access
# '''Compilation/build directories:''' Use flash-based filesystems (Weka, ffuc) or <tt>$TMPDIR</tt> for better performance


* Simple collaboration: Everyone can access the same data
=== For Quota Management ===
* No permission problems: Files automatically get group permissions
* Independent extensions: Team members can extend without original creator
* Easy to find: Use <tt>ws_list -g</tt> to see all team workspaces


'''For advanced sharing options''' (sharing with specific users outside your group, ACL-based methods), see the [[Workspaces/Advanced_Features#Cooperative_Usage_.28Group_Workspaces_and_Sharing.29|Advanced Features guide]].
* Use <tt>ws_release --delete-data</tt> for immediate deletion (see [[#Release_.28Delete.29_Workspace|Release Workspace]])
* For clusters without <tt>--delete-data</tt> option, use [[Workspaces/Advanced_Features#Using_rm_for_Manual_Deletion|manual deletion method]]
* Remember: released workspaces may still count toward quota during grace period (~1 hour)

Revision as of 14:40, 2 December 2025

Note: This is a new Workspaces page. The old wiki can be found here: Workspace.

Workspace tools provide temporary scratch spaces called workspaces for your calculations on central file storage. They are meant to keep data for a limited time – but usually longer than the time of a single job run.

Important - Read Before Using Workspaces:

  • No Backup: Data in workspaces is not backed up and will be automatically deleted after expiration
  • Time-limited: Every workspace has a limited lifetime (typically 30-100 days depending on cluster), see the Cluster-Specific Workspace Limits)
  • Automatic Reminders: You will receive email notifications before expiration
  • Backup Important Data: Copy important results to permanent storage before expiration (check your cluster/site policies for backup locations)

For detailed information about advanced features, configuration options, and less frequently used commands, see the Workspaces/Advanced Features guide.

Command Overview

The workspace tools consist of several commands:

  • ws_allocate - Create or extend a workspace
  • ws_list - List all your workspaces
  • ws_find - Find the path to a workspace
  • ws_extend - Extend the lifetime of a workspace
  • ws_release - Release (delete) a workspace
  • ws_restore - Restore an expired or released workspace
  • ws_register - Create symbolic links to workspaces

All commands support -h or --help to show detailed usage information.

Quick Start - Most Common Commands

Task Command
Create workspace for 30 days ws_allocate myWs 30
Create group-writable workspace ws_allocate -G groupname myWs 30
List all your workspaces ws_list
Check which expire soon ws_list -Rr
Find workspace path (for scripts) ws_find myWs
Extend workspace by 30 days ws_extend myWs 30
Delete/release workspace ws_release myWs
Restore released workspace ws_restore -l then ws_restore oldname newname

Create Workspace

To create a workspace you need to specify a name and lifetime in days:

Basic usage:

  $ ws_allocate myWs 30                    # Create workspace for 30 days

Common variations:

  $ ws_allocate -G groupname myWs 30       # Create group-writable workspace (recommended for teams)
  $ ws_allocate -g myWs 30                 # Create group-readable workspace
  $ ws_allocate -F ffuc myWs 30            # bwUniCluster 3.0: Use flash filesystem

This returns:

  Workspace created. Duration is 720 hours. 
  Further extensions available: 3
  /work/workspace/scratch/username-myWs-0

Important: Creating a workspace a second time with the same command is safe - it always returns the same path.

Capture the path in a variable:

  $ WORKSPACE=$(ws_allocate myWs 30)
  $ cd $WORKSPACE

For all options and advanced usage, see the Advanced Features guide.

List Your Workspaces

Basic usage:

  $ ws_list                                # List all your workspaces

Shows:

  • Workspace ID
  • Workspace location
  • Available extensions
  • Creation date and remaining time

Common variations:

  $ ws_list -Rr                            # Sort by remaining time (see what expires soon)
  $ ws_list -s                             # Short format (only names, good for scripts)
  $ ws_list -g                             # List group workspaces

Note: To list expired workspaces that can be restored, see Restore Workspace.

For all options, see the Advanced Features guide.

Extend Workspace Lifetime

Extend a workspace before it expires:

Basic usage:

  $ ws_extend myWs 30                      # Extend by 30 days from now

Alternative commands:

  $ ws_allocate -x myWs 30                 # Same as ws_extend

Note: Each extension consumes one of your available extensions (see the Cluster-Specific Workspace Limits).

For all options, see the Advanced Features guide.

Release (Delete) Workspace

When you no longer need a workspace:

Basic usage:

  $ ws_release myWs                        # Release workspace (recoverable during grace period)

What happens:

  • Workspace becomes inaccessible immediately
  • Data is kept for a short grace period (usually until next cleanup run) and can be restored with ws_restore
  • Released data may still count toward quota until final deletion

For all options, see the Advanced Features guide.

Restore Workspace

Works on cluster bwUC 3.0 BinAC2 Helix JUSTUS 2 NEMO2
ws_restore

If you released a workspace by accident or need to recover an expired one, you can restore it within a grace period:

Basic workflow:

  $ ws_restore -l                          # (1) List restorable workspaces
  $ ws_allocate restored 60                # (2) Create a new target workspace
  $ ws_restore username-myWs-0 restored    # (3) Restore the expired workspace

Note: Use the full name from ws_restore -l (including username and timestamp), not the short name from ws_list.

For detailed restore options, see the Advanced Features guide.

Work with Groups (Share Workspaces)

Works on cluster bwUC 3.0 BinAC2 Helix JUSTUS 2 NEMO2
-g option (group-readable)
-G option (group-writable)

Working with team members is simple using group workspaces:

Create Group Workspace

Group-readable workspace (team can read):

  $ ws_allocate -g myWs 30

Group-writable workspace (team can read and write, recommended):

  $ ws_allocate -G projectgroup myWs 30

Replace projectgroup with your actual group name (e.g., bw11a000).

Tip: Set your default group in ~/.ws_user.conf to avoid typing it every time:

groupname: projectgroup

Then you only need: ws_allocate myWs 30

List Group Workspaces

See all workspaces from your group:

  $ ws_list -g

This shows workspaces that were created with -g or -G by anyone in your group.

Extend Group Workspace

Anyone in the group can extend a group-writable workspace (-G):

  $ ws_extend myWs 30                      # If you created it
  $ ws_allocate -x -u username myWs 30     # If colleague created it

Replace username with the workspace owner's username. This is useful when they're unavailable.

Manage Reminders for Group Workspace

You can update reminder settings and take over responsibility for reminders on a colleague's workspace:

  $ ws_allocate -r 7 -u username -x myWs 0     # Update reminder time and take over
                                               # another user's workspace reminders

This changes the reminder timing to 7 days before expiration and redirects reminder emails to you instead of the original creator. Useful when you're taking over responsibility for a shared workspace.

Why Use Group Workspaces?

  • Simple collaboration: Everyone can access the same data
  • No permission problems: Files automatically get group permissions
  • Independent extensions: Team members can extend without original creator
  • Easy to find: Use ws_list -g to see all team workspaces

For advanced sharing options (sharing with specific users outside your group, ACL-based methods), see the Advanced Features guide.