|
| 1 | +# Debugging NVMe Namespaces |
| 2 | + |
| 3 | +## Total Space Available or Used |
| 4 | + |
| 5 | +Find the total space available, and the total space used, on a Rabbit node using the Redfish API. One way to access the API is to use the `nnf-node-manager` pod on that node. |
| 6 | + |
| 7 | +To view the space on node ee50, find its `nnf-node-manager` pod and then exec into it to query the Redfish API: |
| 8 | + |
| 9 | +```console |
| 10 | +[richerso@ee1:~]$ kubectl get pods -A -o wide | grep ee50 | grep node-manager |
| 11 | +nnf-system nnf-node-manager-jhglm 1/1 Running 0 61m 10.85.71.11 ee50 <none> <none> |
| 12 | +``` |
| 13 | + |
| 14 | +Then query the Redfish API to view the `AllocatedBytes` and `GuaranteedBytes`: |
| 15 | + |
| 16 | +```console |
| 17 | +[richerso@ee1:~]$ kubectl exec --stdin --tty -n nnf-system nnf-node-manager-jhglm -- curl -S localhost:50057/redfish/v1/StorageServices/NNF/CapacitySource | jq |
| 18 | +{ |
| 19 | + "@odata.id": "/redfish/v1/StorageServices/NNF/CapacitySource", |
| 20 | + "@odata.type": "#CapacitySource.v1_0_0.CapacitySource", |
| 21 | + "Id": "0", |
| 22 | + "Name": "Capacity Source", |
| 23 | + "ProvidedCapacity": { |
| 24 | + "Data": { |
| 25 | + "AllocatedBytes": 128849888, |
| 26 | + "ConsumedBytes": 128849888, |
| 27 | + "GuaranteedBytes": 307132496928, |
| 28 | + "ProvisionedBytes": 307261342816 |
| 29 | + }, |
| 30 | + "Metadata": {}, |
| 31 | + "Snapshot": {} |
| 32 | + }, |
| 33 | + "ProvidedClassOfService": {}, |
| 34 | + "ProvidingDrives": {}, |
| 35 | + "ProvidingPools": {}, |
| 36 | + "ProvidingVolumes": {}, |
| 37 | + "Actions": {}, |
| 38 | + "ProvidingMemory": {}, |
| 39 | + "ProvidingMemoryChunks": {} |
| 40 | +} |
| 41 | +``` |
| 42 | + |
| 43 | +## Total Orphaned or Leaked Space |
| 44 | + |
| 45 | +To determine the amount of orphaned space, look at the Rabbit node when there are no allocations on it. If there are no allocations then there should be no `NnfNodeBlockStorages` in the k8s namespace with the Rabbit's name: |
| 46 | + |
| 47 | +```console |
| 48 | +[richerso@ee1:~]$ kubectl get nnfnodeblockstorage -n ee50 |
| 49 | +No resources found in ee50 namespace. |
| 50 | +``` |
| 51 | + |
| 52 | +To check that there are no orphaned namespaces, you can use the nvme command while logged into that Rabbit node: |
| 53 | + |
| 54 | +```console |
| 55 | +[root@ee50:~]# nvme list |
| 56 | +Node SN Model Namespace Usage Format FW Rev |
| 57 | +--------------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- -------- |
| 58 | +/dev/nvme0n1 S666NN0TB11877 SAMSUNG MZ1L21T9HCLS-00A07 1 8.57 GB / 1.92 TB 512 B + 0 B GDC7302Q |
| 59 | +``` |
| 60 | + |
| 61 | +There should be no namespaces on the kioxia drives: |
| 62 | + |
| 63 | +```console |
| 64 | +[root@ee50:~]# nvme list | grep -i kioxia |
| 65 | +[root@ee50:~]# |
| 66 | +``` |
| 67 | + |
| 68 | +If there are namespaces listed, and there weren't any `NnfNodeBlockStorages` on the node, then they need to be deleted through the Rabbit software. The `NnfNodeECData` resource is a persistent data store for the allocations that should exist on the Rabbit. By deleting it, and then deleting the nnf-node-manager pod, it causes nnf-node-manager to delete the orphaned namespaces. This can take a few minutes after you actually delete the pod: |
| 69 | + |
| 70 | +```console |
| 71 | +kubectl delete nnfnodeecdata ec-data -n ee50 |
| 72 | +kubectl delete pod -n nnf-system nnf-node-manager-jhglm |
| 73 | +``` |
0 commit comments