iSCSI and FC volume plugins do not implement real 3rd party attach/detach.
If reconstruction fails with an error on a FC or iSCSI volume, it will not
be unmounted from the volume global dir and at the same time it will be
marked as unused, to be available to be mounted on another node.
The volume can then be mounted on several nodes, resulting in volume
corruption.
The other block based volume plugins implement attach/detach that either
makes the volume stuck (can't be detached) or will be force-detached from a
node before attaching it somewhere else.
When UnmountDevice() of a FibreChannel volume fails after unmounting the
device and before the device is fully cleaned up, subsequent
UnmountDevice() retry won't find the device mounted and return without
retrying the device cleanup.
Therefore implement its own retry inside UnmountDevice() to make sure that
the volume devices are either fully cleaned or the error is serius enough
that even 1 minute of trying does not help.
Volumes that are provisioned with `VolumeMode: Block` often have a
MetrucsProvider interface declared in their type. However, the
MetricsProvider should implement a GetMetrics() function. In the cases
where the storage drivers do not implement GetMetrics(), a panic can
occur.
Usual type-assertions are not sufficient in this case. All assertions
assume the interface is present. There is no straight forward way to
verify that a valid GetMetrics() function is provided.
By adding SupportsMetrics(), storage driver implementations require
careful reviewing for metrics support.
PR #97972 added support for gathering metrics for Block PVCs provided by
CSI drivers. The in-tree drivers can support at leas the most basic
metric; Capacity.
Similar to how NewMetricsStatFS() works, the new NewMetricsBlock()
provides the GetMetrics() interface for Block volumes.
Additional metrics for Block volumes are difficult to gather. There is
no guarantee that there is a filesystem on the volume, which makes most
of the volume metrics useless.
Advanced storage might be able to detect the actual consumption (when
thin-provisioned) vs the capacity. However, this is out of the scope for
a standard helper function and requires intimate knowledge of the used
storage system.
The non "util-linux" versions of "losetup" don't seem to have
options like "-j" ("--associated") which lists the loop devices
associated with the file, or "--show" which displays the name
of the assigned loop device for a file.
For instance, when "-j" is used, "GetLoopDevice()" fails with:
$ losetup -j /path/to/file
losetup: unrecognized option: j
BusyBox v1.32.1 () multi-call binary.
Add a fallback option to lookup the device from "sysfs" in cases
where "losetup" fails for an invalid option. This can be done by
reading the backing file from "/sys/block/loop*/loop/backing_file"
for each of the devices listed there.
Signed-off-by: Srinidhi Kaushik <shrinidhi.kaushik@gmail.com>
