linstor-server icon indicating copy to clipboard operation
linstor-server copied to clipboard

Linstor CLI shows no "state" and "InUse" for "--layer-list storage"

Open alexzhc opened this issue 4 years ago • 4 comments

Hi, linbit team

In v1.4.3, when "--layer-list storage". linstor cli shows no "state" and "InUse" . In k8s, those raw volumes can be used to support applications that have their own storage replicas, such as MongoDB. Please help fix it.

Thanks

| Node         | Resource                                 | StoragePool  | VolumeNr | MinorNr | DeviceName                                                        | Allocated | InUse  |    State |
|=================================================================================================================================================================================================|
| k8s-worker-3 | pvc-145e4fdc-d31b-4ec8-acec-bb07af32516b | DfltStorPool | 0        | 1000    | /dev/drbd1000                                                     | 11.00 GiB | Unused | UpToDate |
| k8s-worker-9 | pvc-21893c5c-d258-41fe-8b5e-314665b5f3e9 | DfltStorPool | 0        |         | /dev/loop4                                                        | 10 GiB    |        |  Unknown |
| k8s-worker-1 | pvc-7838608d-b81a-449a-ae82-fc3b21da9b01 | LvmStorPool  | 0        |         | /dev/linstor_pool0/pvc-7838608d-b81a-449a-ae82-fc3b21da9b01_00000 | 1.02 MiB  |        |  Unknown |
+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

alexzhc avatar Mar 06 '20 13:03 alexzhc

State and InUse are only shown for those devices where LINSTOR receives such information (typically events) from the system. Currently, it's probably only DRBD (which LINSTOR monitors using the drbdsetup events2 stream). Most of the other storage devices do not provide information on their state. So since there is nothing broken, there is nothing to fix (at least in LINSTOR). The only thing we could do to add such status is to add functionality poll all devices in the list every time a list is generated and possibly figure out whether the devices are in use. This would potentially make generting those lists very slow, so it is questionable whether this would have more advantages or disadvantages. Since kubernetes or its containers are using those storage volumes, information on whether the volumes are in use - and possibly, what the state of the information on those volumes is - should be provided by kubernetes or by the containers using the storage volume. LINSTOR only manages (creates/deletes/changes) those storage volumes, but it is not involved in any I/O, and it is not a monitoring application either.

raltnoeder avatar Mar 09 '20 10:03 raltnoeder

I understand the philosophy here, but would recommend changing state "Unknown" to something more sensible like "Raw" (since it has no drbd layer)

The "InUse" column provides a bottom view of volume mount/umount. Without it, users may only verify volume mount by running 'mount -l' on each host. So having it implemented does help provide consistent user experience.

alexzhc avatar Mar 09 '20 11:03 alexzhc

Changing to something else from "Unknown" is a good recommendation, I will add that to our planned tasks.

Regarding InUse, it actually shows the DRBD role of the resource (Primary or Secondary). Strictly speaking, it does not show whether the resource is in use, it rather shows whether the resource is able to be used for read/write I/O. It may actually show "InUse" for a resource that is in the Primary role, but is not in use, or it may show "Unused" for a resource in the Secondary role that is opened for read-only access. We will investigate whether we can provide more information about any device in this column, if we do, then we will probably not rely on mount status, but on device open/closed status. What I would rather like to avoid is calling yet another external program that is not under our control for fetching this information, because our experience with anything external to LINSTOR is that it introduces unreliability (mostly due to the fact that external utitilies are different on each distribution, or change without warning, and a general lack of standards on anything).

raltnoeder avatar Mar 09 '20 11:03 raltnoeder

If reviving this post is in poor form please let me know, but I wanted to suggest putting the provider type into the "State" field. For example, if a resource was created from an LVM backed storage pool, display "LVM". That way, the user is given a hint as to where they could look next to determine state.

Example output:

# linstor r l
╭────────────────────────────────────────────────────────────────────────────────────╮
┊ ResourceName ┊ Node     ┊ Port ┊ Usage  ┊ Conns ┊      State ┊ CreatedOn           ┊
╞════════════════════════════════════════════════════════════════════════════════════╡
┊ vol1         ┊ linbit-1 ┊      ┊        ┊       ┊        LVM ┊ 2023-09-11 22:02:56 ┊
┊ vol0         ┊ linbit-0 ┊ 7000 ┊ Unused ┊ Ok    ┊   UpToDate ┊ 2023-06-08 17:30:41 ┊
┊ vol0         ┊ linbit-1 ┊ 7000 ┊ Unused ┊ Ok    ┊   UpToDate ┊ 2023-06-08 17:30:41 ┊
┊ vol0         ┊ linbit-2 ┊ 7000 ┊ InUse  ┊ Ok    ┊   Diskless ┊ 2023-06-08 17:30:34 ┊
╰────────────────────────────────────────────────────────────────────────────────────╯

kermat avatar Sep 11 '23 22:09 kermat