From e7a93fb8cda0444c91e33e90f0f715b0b697c841 Mon Sep 17 00:00:00 2001 From: AJ_Datacore Date: Thu, 19 Oct 2023 16:19:16 +0530 Subject: [PATCH 1/4] docs(storageclass-faq): added notes on btrfs in storageclass doc and an faq Signed-off-by: AJ_Datacore --- quickstart/faqs.md | 7 ++++++- reference/storage-class-parameters.md | 8 ++++++-- 2 files changed, 12 insertions(+), 3 deletions(-) diff --git a/quickstart/faqs.md b/quickstart/faqs.md index 10dd9fa..a16b7b5 100644 --- a/quickstart/faqs.md +++ b/quickstart/faqs.md @@ -87,4 +87,9 @@ In Kubernetes, when a PVC is created with the reclaim policy set to 'Retain', th ### How does the PV garbage collector work? - The PV garbage collector deploys a watcher component, which subscribes to the Kubernetes Persistent Volume deletion events. When a PV is deleted, an event is generated by the Kubernetes API server and is received by this component. Upon a successful validation of this event, the garbage collector deletes the corresponding Mayastor volume resources. \ No newline at end of file + The PV garbage collector deploys a watcher component, which subscribes to the Kubernetes Persistent Volume deletion events. When a PV is deleted, an event is generated by the Kubernetes API server and is received by this component. Upon a successful validation of this event, the garbage collector deletes the corresponding Mayastor volume resources. + + +## How to disable cow for btrfs filesystem? + +To disbale cow for `btrfs` filesystem, use `nodatacow` as a mountOption in the storage class which would be used to provision the volume. \ No newline at end of file diff --git a/reference/storage-class-parameters.md b/reference/storage-class-parameters.md index b3ac783..2d31560 100644 --- a/reference/storage-class-parameters.md +++ b/reference/storage-class-parameters.md @@ -12,7 +12,9 @@ The storage class parameter `local` has been deprecated and is a breaking change ## "fsType" -File system that will be used when mounting the volume. The default file system when not specified is 'ext4'. We recommend to use 'xfs' that is considered to be more advanced and performant. Though make sure that XFS is installed on all nodes in the cluster before using it. + +File system that will be used when mounting the volume. +The supported file systems are **ext4**, **xfs** and **btrfs** and the default file system when not specified is **ext4**. We recommend to use **xfs** that is considered to be more advanced and performant. Though make sure that XFS is installed on all nodes in the cluster before using it. ## "ioTimeout" @@ -81,4 +83,6 @@ By default, the `stsAffinityGroup` feature is disabled. To enable it, modify the - When set to `true`, the created clone/restore's filesystem `uuid` will be set to the restore volume's `uuid`. This is important because some file systems, like XFS, do not allow duplicate filesystem `uuid` on the same machine by default. - When set to `false`, the created clone/restore's filesystem `uuid` will be same as the orignal volume `uuid`, but it will be mounted using the `nouuid` flag to bypass duplicate `uuid` validation. - +{% hint style="note" %} +This option needs to be set to true for `btrfs` filesystem, if the application consuming restored volume is to scheduled on the same node. +{% endhint %} From b273ecc2cbf8999e6377c76332b8bdcac6c88fe8 Mon Sep 17 00:00:00 2001 From: AJ_Datacore Date: Sun, 22 Oct 2023 23:55:40 +0530 Subject: [PATCH 2/4] docs(storage-class): addressed comments Signed-off-by: AJ_Datacore --- reference/storage-class-parameters.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/reference/storage-class-parameters.md b/reference/storage-class-parameters.md index 2d31560..20a6e8c 100644 --- a/reference/storage-class-parameters.md +++ b/reference/storage-class-parameters.md @@ -12,9 +12,9 @@ The storage class parameter `local` has been deprecated and is a breaking change ## "fsType" - File system that will be used when mounting the volume. -The supported file systems are **ext4**, **xfs** and **btrfs** and the default file system when not specified is **ext4**. We recommend to use **xfs** that is considered to be more advanced and performant. Though make sure that XFS is installed on all nodes in the cluster before using it. +The supported file systems are **ext4**, **xfs** and **btrfs** and the default file system when not specified is **ext4**. We recommend to use **xfs** that is considered to be more advanced and performant. +Please ensure the requested filesystem driver is installed on all worker nodes in the cluster before using it. ## "ioTimeout" @@ -84,5 +84,5 @@ By default, the `stsAffinityGroup` feature is disabled. To enable it, modify the - When set to `false`, the created clone/restore's filesystem `uuid` will be same as the orignal volume `uuid`, but it will be mounted using the `nouuid` flag to bypass duplicate `uuid` validation. {% hint style="note" %} -This option needs to be set to true for `btrfs` filesystem, if the application consuming restored volume is to scheduled on the same node. +This option needs to be set to true when using a `btrfs` filesystem, if the application using the restored volume is scheduled on the same node where the the original volume is mounted, concurrently. {% endhint %} From dc6b82be249d0838cb311d3ade4b8a11c58030ea Mon Sep 17 00:00:00 2001 From: AJ_Datacore <135806464+AJDatacore@users.noreply.github.com> Date: Sun, 22 Oct 2023 23:46:51 +0530 Subject: [PATCH 3/4] docs(storageclass): resolved conflicts Co-authored-by: Tiago Castro Signed-off-by: AJ_Datacore --- reference/storage-class-parameters.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/reference/storage-class-parameters.md b/reference/storage-class-parameters.md index 20a6e8c..bc2e7b7 100644 --- a/reference/storage-class-parameters.md +++ b/reference/storage-class-parameters.md @@ -84,5 +84,5 @@ By default, the `stsAffinityGroup` feature is disabled. To enable it, modify the - When set to `false`, the created clone/restore's filesystem `uuid` will be same as the orignal volume `uuid`, but it will be mounted using the `nouuid` flag to bypass duplicate `uuid` validation. {% hint style="note" %} -This option needs to be set to true when using a `btrfs` filesystem, if the application using the restored volume is scheduled on the same node where the the original volume is mounted, concurrently. +This option needs to be set to true when using a `btrfs` filesystem, if the application using the restored volume is scheduled on the same node where the original volume is mounted, concurrently. {% endhint %} From 18df704bda70c33d34898dc269e7db9bd2d96f93 Mon Sep 17 00:00:00 2001 From: AJ_Datacore Date: Thu, 16 Nov 2023 14:40:29 +0530 Subject: [PATCH 4/4] docs(known-limitations): removed info on snapshot and clones Signed-off-by: AJ_Datacore --- quickstart/known-limitations.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/quickstart/known-limitations.md b/quickstart/known-limitations.md index 507bf9f..ec053fb 100644 --- a/quickstart/known-limitations.md +++ b/quickstart/known-limitations.md @@ -4,10 +4,6 @@ Once provisioned, neither Mayastor Disk Pools nor Mayastor Volumes can be re-sized. A Mayastor Pool can have only a single block device as a member. Mayastor Volumes are exclusively thick-provisioned. -## Snapshots and Clones - -Mayastor has no snapshot or cloning capabilities. - ## Volumes are "Highly Durable" but without multipathing are not "Highly Available" Mayastor Volumes can be configured \(or subsequently re-configured\) to be composed of 2 or more "children" or "replicas"; causing synchronously mirrored copies of the volumes's data to be maintained on more than one worker node and Disk Pool. This contributes additional "durability" at the persistence layer, ensuring that viable copies of a volume's data remain even if a Disk Pool device is lost.