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:
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 KMS management.
View filesystems
Command: weka fs
Use this command to view information on the filesystems in the WEKA system.
Create a filesystem
Command: weka fs create
Use the following command line to create a filesystem:
weka fs create <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>] [--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] [--allow-no-kms] [--data-reduction]
Parameters
| Name | Value | Default |
|---|---|---|
| Descriptive label for the filesystem, limited to 32 characters and excluding slashes ( | |
| Name of the filesystem group to which the new filesystem is to be connected. | |
| Total capacity of the new filesystem. Minimum value: 1GiB. | |
| Object store name for tiering. Mandatory for tiered filesystems. | |
| For tiered filesystems, this is the SSD capacity. If not specified, the filesystem is pinned to SSD.
To set a thin provisioned filesystem, the | SSD capacity is set to total capacity |
| 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. | |
| For thin-provisioned filesystem, this is the maximum SSD capacity the filesystem can consume.
The value cannot exceed the | |
| Customize KMS key identifier for this filesystem (only for HashiCorp Vault). | |
| Customize KMS namespace for this filesystem (only for HashiCorp Vault). | |
| Customize KMS role-id for this filesystem (only for HashiCorp Vault). | |
| Customize KMS secret-id for this filesystem (only for HashiCorp Vault). | |
| 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: | No |
| Encryption of filesystem. | No |
| Allows the creation of an encrypted filesystem without a KMS configured, though this is considered insecure. | No |
| Enable data reduction. The filesystem must be non-tired and thin-provisioned. A license with data reduction is required. | No |
When creating an encrypted filesystem a KMS must be defined.
To define an encrypted filesystem without a KMS, it is possible to use the--allow-no-kms parameter in the command. This can be useful when running POCs but should not be used in production since the security chain is compromised when a KMS is not used.
If filesystem keys exist when adding a KMS, they are automatically re-encrypted by the KMS for any future use.
Add a filesystem when thin-provisioning is used
To create a new filesystem, the SSD space for the filesystem must be free and unprovisioned. When using thin-provisioned filesystems, that might not be the case. SSD space can be occupied for the thin-provisioned portion of other filesystems. Even if those are tiered, and data can be released (to object-store) or deleted, the SSD space can still get filled when data keeps being written or promoted from the object-store.
To create a new filesystem, in this case, use the weka fs reserve CLI command. Once enough space is cleared from the SSD (either by releasing to object-store or explicitly deleting data), it is possible to create the new filesystem using the reserved space.
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] [--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 of the filesystem to edit. |
| New name for the filesystem. |
| Total capacity of the edited filesystem. |
| SSD capacity of the edited filesystem. Minimum value: 1GiB. |
| For thin-provisioned filesystems, this is the minimum SSD capacity that is ensured to be always available to this filesystem. Minimum value: 1GiB. |
| For thin-proviosined filesystem, this is the maximum SSD capacity the filesystem can consume.
The value must not exceed the |
| Enable data reduction. The filesystem must be non-tired and thin-provisioned. A license with data reduction is required. |
| Determines if mounting the filesystem requires being authenticated to Weka (weka user login).
Possible values: |
| Customize KMS key identifier for this filesystem (only for HashiCorp Vault). |
| Customize KMS namespace for this filesystem (only for HashiCorp Vault). |
| Customize KMS role-id for this filesystem (only for HashiCorp Vault). |
| Customize KMS secret-id for this filesystem (only for HashiCorp Vault). |
| Enable cluster KMS configuration for this filesystem, which removes any custom KMS settings previously applied to it. |
Delete a filesystem
Command: weka fs delete
Use the following command line to delete a filesystem:
weka fs delete <name> [--purge-from-obs]
Parameters
| Name | Value | Default |
|---|---|---|
| Name of the filesystem to delete. | |
| 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 |
|---|---|
| Filesystem name |
Last updated