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.
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>
Fix inode usage calculation to use filepath.Walk instead of executing an
external find. Also calculate the disk usage while at it so we also get
rid of the external dependency of `nice` and `du`. (#95172)
This is similar to what cadvisor does since commit
046818d64c
This solves three problems:
- Counts number of inodes correct when there are hardlinks (#96114)
- Makes kubelet work without GNU findutils (#95186)
- Makes kubelet work without GNU coreutils (#95172)
The goal of this move is related to issue 89930, to break the dependence
of scheduling plugins on internal helpers. This function can easily move to
component-helpers where it will be used by other components as well.
When creating a symlink on Windows, if the target does not exist, the created
file is just a regular "symlink" file. But, if the target ultimately ends up being
a folder, then that symlink file is not valid, it must be a "symlinkd" in order to function
properly. Because the symlink file is not valid, the pods having that volume will fail to start.
Creating the user-visible files after the timestamped and data folders have been created
addresses this issue.
In case /var/lib/kubelet is a symlink, "losetup -j <device in
/var/lib/kubelet>" will show the device paths with symlinks fully
evaluated.
Fix the parsing routine and expand symlinks in the path that we want to
find in "losetup -j" output.
