Manage filesystems using the CLI

This page describes how to view and manage filesystems using the CLI.

Using the CLI, you can perform the following actions:

• View filesystems

• Add a filesystem

• Add a filesystem when thin-provisioning is used

• Edit a filesystem

• Remove a filesystem

• Rewrap the filesystem encryption key

Several parameters in this topic relate to Key Management System (KMS) configuration, which supports both per-filesystem encryption keys and cluster encryption keys. For more information about how KMS integration works and setup guidance, see Manage KMS.

View filesystems

Command: weka fs

Use this command to view information on the filesystems in the WEKA system.

Add a filesystem

Command: weka fs add

Use the following command line to create a filesystem:

weka fs add <name> <group-name> <total-capacity> [--obs-name <obs-name>] [--ssd-capacity <ssd-capacity>] [--thin-provision-min-ssd <thin-provision-min-ssd>] [--thin-provision-max-ssd <thin-provision-max-ssd>] [--audit] [--kms-key-identifier kms-key-identifier] [--kms-namespace kms-namespace] [--kms-role-id kms-role-id] [--kms-secret-id kms-secret-id] [--auth-required auth-required] [--encrypted] [--data-reduction]

Parameters

Name	Value	Default
name*	A descriptive label for the filesystem, limited to 32 characters and excluding slash (/) or backslash (\).	​
group-name*	Name of the filesystem group to which the new filesystem is to be connected.
total-capacity*	Total capacity of the new filesystem. Minimum value: 1GiB.
obs-name	Object store name for tiering. Mandatory for tiered filesystems.
ssd-capacity	Specifies the SSD capacity to allocate for a tiered file system. If this parameter is not specified, the file system is fully pinned to SSD storage. When specified, the SSD capacity defines the portion of total capacity that resides on SSD. The recommended best practice is to maintain a 1:4 ratio between the SSD capacity and the total capacity of the file system. To create a thin-provisioned file system, use the thin-provision-min-ssd attribute instead.	As set in total-capacity
thin-provision-min-ssd	For thin-provisioned filesystems, this is the minimum SSD capacity that is ensured to be always available to this filesystem. Must be set when defining a thin-provisioned filesystem. Minimum value: 1GiB.
thin-provision-max-ssd	For thin-provisioned filesystem, this is the maximum SSD capacity the filesystem can consume. The value cannot exceed the total-capacity.
audit	Forwards this filesystem's audit logs to a configured events monitoring platform, provided that cluster-wide auditing is also enabled.
kms-key-identifier	Customize KMS key identifier for this filesystem (only for HashiCorp Vault).
kms-namespace	Customize KMS namespace for this filesystem (only for HashiCorp Vault).
kms-role-id	Customize KMS role-id for this filesystem (only for HashiCorp Vault).
kms-secret-id	Customize KMS secret-id for this filesystem (only for HashiCorp Vault).
auth-required	Require the mounting user to be authenticated for mounting this filesystem. This flag is only effective in the root organization, users in non-root organizations must be authenticated to perform a mount operation. Format: yes or no. See User management.	No
encrypted	Encryption of filesystem.	No
data-reduction	Enable data reduction. The filesystem must be non-tired and thin-provisioned. A license with data reduction is required.	No

To create an encrypted filesystem, you must define a KMS.

If a KMS is unavailable for a POC, contact the Customer Success Team for guidance.

Add a filesystem with thin-provisioning

When adding a new filesystem, you need unprovisioned SSD space. With thin provisioning, existing filesystems may be using their provisioned SSD space in two ways:

• Actively storing data.

• Holding space available for potential data promotions from object-store.

Even if existing filesystems are tiered, their SSD space might remain occupied due to:

• Continuous new data writes.

• Ongoing data promotions from object-store to SSD tier.

To ensure space for a new filesystem, follow these steps:

1. Use the weka fs reserve CLI command to reserve the required SSD space.

2. Wait for the system to free up sufficient SSD space through either:

   • Automatic data release to object-store.

   • Manual data deletion.

3. Create the new filesystem using the reserved space.

This ensures the new filesystem has its required minimum capacity while maintaining the performance of existing filesystems.

Edit a filesystem

Command: weka fs update

Use the following command line to edit an existing filesystem:

weka fs update <name> [--new-name new-name] [--total-capacity total-capacity] [--ssd-capacity ssd-capacity] [--thin-provision-min-ssd thin-provision-min-ssd] [--thin-provision-max-ssd thin-provision-max-ssd] [--audit] [--data-reduction data-reduction] [--auth-required auth-required] [--kms-key-identifier kms-key-identifier] [--kms-namespace kms-namespace] [--kms-role-id kms-role-id] [--kms-secret-id kms-secret-id] [--use-cluster-kms-key-identifier]

Parameters

Name	Value
name*	Name of the filesystem to edit.
new-name	New name for the filesystem.
total-capacity	Total capacity of the edited filesystem.
ssd-capacity	SSD capacity of the edited filesystem. Minimum value: 1GiB.
thin-provision-min-ssd	For thin-provisioned filesystems, this is the minimum SSD capacity that is ensured to be always available to this filesystem. Minimum value: 1GiB.
thin-provision-max-ssd	For thin-proviosined filesystem, this is the maximum SSD capacity the filesystem can consume. The value must not exceed the total-capacity.
audit	Forwards this filesystem's audit logs to a configured events monitoring platform, provided that cluster-wide auditing is also enabled.
data-reduction	Enable data reduction. The filesystem must be non-tired and thin-provisioned. A license with data reduction is required.
auth-required	Determines if mounting the filesystem requires being authenticated to Weka (weka user login). Possible values: yes or no.
kms-key-identifier	Customize KMS key identifier for this filesystem (only for HashiCorp Vault).
kms-namespace	Customize KMS namespace for this filesystem (only for HashiCorp Vault).
kms-role-id	Customize KMS role-id for this filesystem (only for HashiCorp Vault).
kms-secret-id	Customize KMS secret-id for this filesystem (only for HashiCorp Vault).
use-cluster-kms-key-identifier	Enable cluster KMS configuration for this filesystem, which removes any custom KMS settings previously applied to it.

Remove a filesystem

Command: weka fs remove

Use the following command line to remove a filesystem:

weka fs remove <name> [--purge-from-obs]

Parameters

Name	Value	Default
name*	Name of the filesystem to delete.
purge-from-obs	For a tiered filesystem, if set, all filesystem data is deleted from the object store bucket.	False

Using purge-from-obs removes all data from the object-store. This includes any backup data or snapshots created from this filesystem (if this filesystem has been downloaded from a snapshot of a different filesystem, it will leave the original snapshot data intact).

• If any of the removed snapshots have been (or are) downloaded and used by a different filesystem, that filesystem will stop functioning correctly, data might be unavailable and errors might occur when accessing the data.

It is possible to either un-tier or migrate such a filesystem to a different object store bucket before deleting the snapshots it has downloaded.

Rewrap the filesystem encryption key

Command: weka fs kms-rewrap

Rewrap operations can be performed per filesystem, enabling each key to be re-encrypted with a new version if there are concerns about key compromise. Use the following command to run this operation:

weka fs kms-rewrap <name>

Parameters

Parameter	Description
name*	Filesystem name