| 2023-10-18 17:39:42 |
Jorge Merlino |
bug |
|
|
added bug |
| 2023-10-18 17:40:03 |
Jorge Merlino |
nominated for series |
|
Ubuntu Focal |
|
| 2023-10-18 17:40:03 |
Jorge Merlino |
bug task added |
|
multipath-tools (Ubuntu Focal) |
|
| 2023-10-18 17:40:48 |
Jorge Merlino |
multipath-tools (Ubuntu): status |
New |
Fix Released |
|
| 2023-10-19 16:42:53 |
Andrew Cloke |
bug |
|
|
added subscriber Andrew Cloke |
| 2023-10-27 17:48:08 |
Mauricio Faria de Oliveira |
bug |
|
|
added subscriber Mauricio Faria de Oliveira |
| 2023-10-27 17:52:31 |
Jorge Merlino |
attachment added |
|
lp2039719_focal.debdiff https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/2039719/+attachment/5713819/+files/lp2039719_focal.debdiff |
|
| 2023-10-28 17:14:23 |
Mauricio Faria de Oliveira |
bug |
|
|
added subscriber Support Engineering Sponsors |
| 2023-10-29 00:05:48 |
Mauricio Faria de Oliveira |
multipath-tools (Ubuntu Focal): status |
New |
Incomplete |
|
| 2023-10-29 00:05:50 |
Mauricio Faria de Oliveira |
multipath-tools (Ubuntu Focal): importance |
Undecided |
Medium |
|
| 2023-10-29 00:06:00 |
Mauricio Faria de Oliveira |
multipath-tools (Ubuntu Focal): assignee |
|
Jorge Merlino (jorge-merlino) |
|
| 2023-10-29 00:12:44 |
Mauricio Faria de Oliveira |
attachment added |
|
lp2039719_focal_v2.debdiff https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/2039719/+attachment/5714075/+files/lp2039719_focal_v2.debdiff |
|
| 2023-11-07 19:41:20 |
Mauricio Faria de Oliveira |
description |
[Impact]
In a server with high volume of multipath volume creation and teardown it can occur a race condition that keeps a multipath volume that should have been removed with no devices or with failed or unknown devices.
In particular this occurs when a multipath device is removed during, or immediately before the call to check_path(). A missing multipath device will cause update_multipath_strings() to fail, setting pp->dmstate to PSTATE_UNDEF. If the path is up, this state will cause reinstate_path() to be called, which will also fail. This will trigger a reload, restoring the recently removed device in an invalid state.
[Test Plan]
This can be reproduced by one of our customers on a Kubernetes installation using Netapp Trident for storage orchestration.
[Where problems could occur]
We are merging two patches here (both done by the same person on the same day). One just changes the return value of some functions from a boolean to symbolic codes to differentiate errors. The other one uses this new error codes to change the behavior of the check_path() function. These changes affect only the error paths so this should not break anything when the code works without errors. It is possible that problems could occur during error handling.
[Other Info]
This patch only needs to be applied to Focal as it is already included in the Jammy version. |
[Impact]
In a server with high volume of multipath volume creation and teardown it can occur a race condition that keeps a multipath volume that should have been removed with no devices or with failed or unknown devices.
In particular this occurs when a multipath device is removed during, or immediately before the call to check_path(). A missing multipath device will cause update_multipath_strings() to fail, setting pp->dmstate to PSTATE_UNDEF.
If the path is up, this state will cause reinstate_path() to be called, which will also fail. This will trigger a reload, restoring the recently removed device in an invalid state.
The command "multipathd show config" fails with "timeout receiving packet".
The command "multipath -ll" shows errors and names/paths as '#' (unexpected):
Sep 28 20:31:20 | 65:208: cannot find block device
Sep 28 20:31:20 | 65:208: Empty device name
Sep 28 20:31:20 | 65:208: Empty device name
Sep 28 20:31:20 | 65:240: cannot find block device
Sep 28 20:31:20 | 65:240: Empty device name
Sep 28 20:31:20 | 65:240: Empty device name
Sep 28 20:31:20 | 65:224: cannot find block device
Sep 28 20:31:20 | 65:224: Empty device name
Sep 28 20:31:20 | 65:224: Empty device name
Sep 28 20:31:20 | 66:0: cannot find block device
Sep 28 20:31:20 | 66:0: Empty device name
Sep 28 20:31:20 | 66:0: Empty device name
3600a098038305768462b564d48336636 dm-38 ##,##
size=19G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=0 status=enabled
| |- #:#:#:# - #:# failed undef unknown
| `- #:#:#:# - #:# failed undef unknown
`-+- policy='service-time 0' prio=0 status=enabled
|- #:#:#:# - #:# failed undef unknown
`- #:#:#:# - #:# failed undef unknown
[Test Plan]
This can be reproduced by one of our customers on a Kubernetes installation using Netapp Trident for storage orchestration.
Continuously add and remove all the individual paths for storage devices in
order to create and remove multipath devices managed by multipathd.
[Where problems could occur]
We are merging two patches here (both done by the same person on the same day). One just changes the return value of some functions from a boolean to symbolic codes to differentiate errors. The other one uses this new error codes to change the behavior of the check_path() function. These changes affect only the error paths so this should not break anything when the code works without errors. It is possible that problems could occur during error handling.
[Other Info]
This patch only needs to be applied to Focal as it is already included in the Jammy version. |
|
| 2023-11-07 19:43:05 |
Mauricio Faria de Oliveira |
description |
[Impact]
In a server with high volume of multipath volume creation and teardown it can occur a race condition that keeps a multipath volume that should have been removed with no devices or with failed or unknown devices.
In particular this occurs when a multipath device is removed during, or immediately before the call to check_path(). A missing multipath device will cause update_multipath_strings() to fail, setting pp->dmstate to PSTATE_UNDEF.
If the path is up, this state will cause reinstate_path() to be called, which will also fail. This will trigger a reload, restoring the recently removed device in an invalid state.
The command "multipathd show config" fails with "timeout receiving packet".
The command "multipath -ll" shows errors and names/paths as '#' (unexpected):
Sep 28 20:31:20 | 65:208: cannot find block device
Sep 28 20:31:20 | 65:208: Empty device name
Sep 28 20:31:20 | 65:208: Empty device name
Sep 28 20:31:20 | 65:240: cannot find block device
Sep 28 20:31:20 | 65:240: Empty device name
Sep 28 20:31:20 | 65:240: Empty device name
Sep 28 20:31:20 | 65:224: cannot find block device
Sep 28 20:31:20 | 65:224: Empty device name
Sep 28 20:31:20 | 65:224: Empty device name
Sep 28 20:31:20 | 66:0: cannot find block device
Sep 28 20:31:20 | 66:0: Empty device name
Sep 28 20:31:20 | 66:0: Empty device name
3600a098038305768462b564d48336636 dm-38 ##,##
size=19G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=0 status=enabled
| |- #:#:#:# - #:# failed undef unknown
| `- #:#:#:# - #:# failed undef unknown
`-+- policy='service-time 0' prio=0 status=enabled
|- #:#:#:# - #:# failed undef unknown
`- #:#:#:# - #:# failed undef unknown
[Test Plan]
This can be reproduced by one of our customers on a Kubernetes installation using Netapp Trident for storage orchestration.
Continuously add and remove all the individual paths for storage devices in
order to create and remove multipath devices managed by multipathd.
[Where problems could occur]
We are merging two patches here (both done by the same person on the same day). One just changes the return value of some functions from a boolean to symbolic codes to differentiate errors. The other one uses this new error codes to change the behavior of the check_path() function. These changes affect only the error paths so this should not break anything when the code works without errors. It is possible that problems could occur during error handling.
[Other Info]
This patch only needs to be applied to Focal as it is already included in the Jammy version. |
[Impact]
In a server with high volume of multipath volume creation and teardown it can occur a race condition that keeps a multipath volume that should have been removed with no devices or with failed or unknown devices.
In particular this occurs when a multipath device is removed during, or immediately before the call to check_path(). A missing multipath device will cause update_multipath_strings() to fail, setting pp->dmstate to PSTATE_UNDEF.
If the path is up, this state will cause reinstate_path() to be called, which will also fail. This will trigger a reload, restoring the recently removed device in an invalid state.
The command "multipathd show config" fails with "timeout receiving packet".
The command "multipath -ll" shows errors and names/paths as '#' (unexpected):
Sep 28 20:31:20 | 65:208: cannot find block device
Sep 28 20:31:20 | 65:208: Empty device name
Sep 28 20:31:20 | 65:208: Empty device name
Sep 28 20:31:20 | 65:240: cannot find block device
Sep 28 20:31:20 | 65:240: Empty device name
Sep 28 20:31:20 | 65:240: Empty device name
Sep 28 20:31:20 | 65:224: cannot find block device
Sep 28 20:31:20 | 65:224: Empty device name
Sep 28 20:31:20 | 65:224: Empty device name
Sep 28 20:31:20 | 66:0: cannot find block device
Sep 28 20:31:20 | 66:0: Empty device name
Sep 28 20:31:20 | 66:0: Empty device name
3600a098038305768462b564d48336636 dm-38 ##,##
size=19G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=0 status=enabled
| |- #:#:#:# - #:# failed undef unknown
| `- #:#:#:# - #:# failed undef unknown
`-+- policy='service-time 0' prio=0 status=enabled
|- #:#:#:# - #:# failed undef unknown
`- #:#:#:# - #:# failed undef unknown
[Test Plan]
This can be reproduced by one of our customers on a Kubernetes installation using Netapp Trident for storage orchestration.
Continuously add and remove all the individual paths for storage devices in
order to create and remove multipath devices managed by multipathd, while
checking the output of `multipath -ll`.
[Where problems could occur]
We are merging two patches here (both done by the same person on the same day). One just changes the return value of some functions from a boolean to symbolic codes to differentiate errors. The other one uses this new error codes to change the behavior of the check_path() function. These changes affect only the error paths so this should not break anything when the code works without errors. It is possible that problems could occur during error handling.
[Other Info]
This patch only needs to be applied to Focal as it is already included in the Jammy version. |
|
| 2023-11-07 19:47:55 |
Mauricio Faria de Oliveira |
description |
[Impact]
In a server with high volume of multipath volume creation and teardown it can occur a race condition that keeps a multipath volume that should have been removed with no devices or with failed or unknown devices.
In particular this occurs when a multipath device is removed during, or immediately before the call to check_path(). A missing multipath device will cause update_multipath_strings() to fail, setting pp->dmstate to PSTATE_UNDEF.
If the path is up, this state will cause reinstate_path() to be called, which will also fail. This will trigger a reload, restoring the recently removed device in an invalid state.
The command "multipathd show config" fails with "timeout receiving packet".
The command "multipath -ll" shows errors and names/paths as '#' (unexpected):
Sep 28 20:31:20 | 65:208: cannot find block device
Sep 28 20:31:20 | 65:208: Empty device name
Sep 28 20:31:20 | 65:208: Empty device name
Sep 28 20:31:20 | 65:240: cannot find block device
Sep 28 20:31:20 | 65:240: Empty device name
Sep 28 20:31:20 | 65:240: Empty device name
Sep 28 20:31:20 | 65:224: cannot find block device
Sep 28 20:31:20 | 65:224: Empty device name
Sep 28 20:31:20 | 65:224: Empty device name
Sep 28 20:31:20 | 66:0: cannot find block device
Sep 28 20:31:20 | 66:0: Empty device name
Sep 28 20:31:20 | 66:0: Empty device name
3600a098038305768462b564d48336636 dm-38 ##,##
size=19G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=0 status=enabled
| |- #:#:#:# - #:# failed undef unknown
| `- #:#:#:# - #:# failed undef unknown
`-+- policy='service-time 0' prio=0 status=enabled
|- #:#:#:# - #:# failed undef unknown
`- #:#:#:# - #:# failed undef unknown
[Test Plan]
This can be reproduced by one of our customers on a Kubernetes installation using Netapp Trident for storage orchestration.
Continuously add and remove all the individual paths for storage devices in
order to create and remove multipath devices managed by multipathd, while
checking the output of `multipath -ll`.
[Where problems could occur]
We are merging two patches here (both done by the same person on the same day). One just changes the return value of some functions from a boolean to symbolic codes to differentiate errors. The other one uses this new error codes to change the behavior of the check_path() function. These changes affect only the error paths so this should not break anything when the code works without errors. It is possible that problems could occur during error handling.
[Other Info]
This patch only needs to be applied to Focal as it is already included in the Jammy version. |
[Impact]
In a server with high volume of multipath volume creation and teardown it can occur a race condition that keeps a multipath volume that should have been removed with no devices or with failed or unknown devices.
In particular this occurs when a multipath device is removed during, or immediately before the call to check_path(). A missing multipath device will cause update_multipath_strings() to fail, setting pp->dmstate to PSTATE_UNDEF.
If the path is up, this state will cause reinstate_path() to be called, which will also fail. This will trigger a reload, restoring the recently removed device in an invalid state.
The command "multipathd show config" fails with "timeout receiving packet".
The command "multipath -ll" shows errors and names/paths as '#' (unexpected):
Sep 28 20:31:20 | 65:208: cannot find block device
Sep 28 20:31:20 | 65:208: Empty device name
Sep 28 20:31:20 | 65:208: Empty device name
Sep 28 20:31:20 | 65:240: cannot find block device
Sep 28 20:31:20 | 65:240: Empty device name
Sep 28 20:31:20 | 65:240: Empty device name
Sep 28 20:31:20 | 65:224: cannot find block device
Sep 28 20:31:20 | 65:224: Empty device name
Sep 28 20:31:20 | 65:224: Empty device name
Sep 28 20:31:20 | 66:0: cannot find block device
Sep 28 20:31:20 | 66:0: Empty device name
Sep 28 20:31:20 | 66:0: Empty device name
3600a098038305768462b564d48336636 dm-38 ##,##
size=19G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=0 status=enabled
| |- #:#:#:# - #:# failed undef unknown
| `- #:#:#:# - #:# failed undef unknown
`-+- policy='service-time 0' prio=0 status=enabled
|- #:#:#:# - #:# failed undef unknown
`- #:#:#:# - #:# failed undef unknown
[Test Plan]
This can be reproduced by one of our customers on a Kubernetes installation using Netapp Trident for storage orchestration.
Continuously add and remove all the individual paths for storage devices in
order to create and remove multipath devices managed by multipathd, while
checking the output of `multipath -ll`.
[Where problems could occur]
We are merging two patches here (both done by the same person on the same day).
- One just changes the return value of some functions from a boolean to symbolic codes to differentiate errors.
- The other one uses this new error codes to change the behavior of the check_path() function.
These changes mostly affect the error paths so this should not break anything
when the code works without errors, but theoretically might also affect the
normal path of periodically checking path status -- fortunaly this runs very
often, thus regressions should be easy and quick to spot during tests.
There are 2 additional patches upstream for the lines changed by these patches,
which are NULL pointer checks, and are introduced here too.
[Other Info]
Most patches only needs to be applied to Focal as it is already included in the Jammy version. One |
|
| 2023-11-07 19:49:31 |
Mauricio Faria de Oliveira |
description |
[Impact]
In a server with high volume of multipath volume creation and teardown it can occur a race condition that keeps a multipath volume that should have been removed with no devices or with failed or unknown devices.
In particular this occurs when a multipath device is removed during, or immediately before the call to check_path(). A missing multipath device will cause update_multipath_strings() to fail, setting pp->dmstate to PSTATE_UNDEF.
If the path is up, this state will cause reinstate_path() to be called, which will also fail. This will trigger a reload, restoring the recently removed device in an invalid state.
The command "multipathd show config" fails with "timeout receiving packet".
The command "multipath -ll" shows errors and names/paths as '#' (unexpected):
Sep 28 20:31:20 | 65:208: cannot find block device
Sep 28 20:31:20 | 65:208: Empty device name
Sep 28 20:31:20 | 65:208: Empty device name
Sep 28 20:31:20 | 65:240: cannot find block device
Sep 28 20:31:20 | 65:240: Empty device name
Sep 28 20:31:20 | 65:240: Empty device name
Sep 28 20:31:20 | 65:224: cannot find block device
Sep 28 20:31:20 | 65:224: Empty device name
Sep 28 20:31:20 | 65:224: Empty device name
Sep 28 20:31:20 | 66:0: cannot find block device
Sep 28 20:31:20 | 66:0: Empty device name
Sep 28 20:31:20 | 66:0: Empty device name
3600a098038305768462b564d48336636 dm-38 ##,##
size=19G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=0 status=enabled
| |- #:#:#:# - #:# failed undef unknown
| `- #:#:#:# - #:# failed undef unknown
`-+- policy='service-time 0' prio=0 status=enabled
|- #:#:#:# - #:# failed undef unknown
`- #:#:#:# - #:# failed undef unknown
[Test Plan]
This can be reproduced by one of our customers on a Kubernetes installation using Netapp Trident for storage orchestration.
Continuously add and remove all the individual paths for storage devices in
order to create and remove multipath devices managed by multipathd, while
checking the output of `multipath -ll`.
[Where problems could occur]
We are merging two patches here (both done by the same person on the same day).
- One just changes the return value of some functions from a boolean to symbolic codes to differentiate errors.
- The other one uses this new error codes to change the behavior of the check_path() function.
These changes mostly affect the error paths so this should not break anything
when the code works without errors, but theoretically might also affect the
normal path of periodically checking path status -- fortunaly this runs very
often, thus regressions should be easy and quick to spot during tests.
There are 2 additional patches upstream for the lines changed by these patches,
which are NULL pointer checks, and are introduced here too.
[Other Info]
Most patches only needs to be applied to Focal as it is already included in the Jammy version. One |
[Impact]
In a server with high volume of multipath volume creation and teardown it can occur a race condition that keeps a multipath volume that should have been removed with no devices or with failed or unknown devices.
In particular this occurs when a multipath device is removed during, or immediately before the call to check_path(). A missing multipath device will cause update_multipath_strings() to fail, setting pp->dmstate to PSTATE_UNDEF.
If the path is up, this state will cause reinstate_path() to be called, which will also fail. This will trigger a reload, restoring the recently removed device in an invalid state.
The command "multipathd show config" fails with "timeout receiving packet".
The command "multipath -ll" shows errors and names/paths as '#' (unexpected):
Sep 28 20:31:20 | 65:208: cannot find block device
Sep 28 20:31:20 | 65:208: Empty device name
Sep 28 20:31:20 | 65:208: Empty device name
Sep 28 20:31:20 | 65:240: cannot find block device
Sep 28 20:31:20 | 65:240: Empty device name
Sep 28 20:31:20 | 65:240: Empty device name
Sep 28 20:31:20 | 65:224: cannot find block device
Sep 28 20:31:20 | 65:224: Empty device name
Sep 28 20:31:20 | 65:224: Empty device name
Sep 28 20:31:20 | 66:0: cannot find block device
Sep 28 20:31:20 | 66:0: Empty device name
Sep 28 20:31:20 | 66:0: Empty device name
3600a098038305768462b564d48336636 dm-38 ##,##
size=19G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=0 status=enabled
| |- #:#:#:# - #:# failed undef unknown
| `- #:#:#:# - #:# failed undef unknown
`-+- policy='service-time 0' prio=0 status=enabled
|- #:#:#:# - #:# failed undef unknown
`- #:#:#:# - #:# failed undef unknown
[Test Plan]
This can be reproduced by one of our customers on a Kubernetes installation using Netapp Trident for storage orchestration.
Continuously add and remove all the individual paths for storage devices in
order to create and remove multipath devices managed by multipathd, while
checking the output of `multipath -ll`.
[Where problems could occur]
We are merging two patches here (both done by the same person on the same day).
- One just changes the return value of some functions from a boolean to symbolic codes to differentiate errors.
- The other one uses this new error codes to change the behavior of the check_path() function.
These changes mostly affect the error paths so this should not break anything
when the code works without errors, but theoretically might also affect the
normal path of periodically checking path status -- fortunaly this runs very
often, thus regressions should be easy and quick to spot during tests.
There are 2 additional upstream patches for the lines changed by these patches,
which are NULL pointer checks, and are introduced here too.
[Other Info]
Most patches only needs to be applied to Focal as it is already included in the Jammy version.
One of the additional upstream patches needs to go to Jammy and Lunar, which is
done in bug 2042366 in order to get specific/individual testing on the releases. |
|
| 2023-11-07 19:50:05 |
Mauricio Faria de Oliveira |
description |
[Impact]
In a server with high volume of multipath volume creation and teardown it can occur a race condition that keeps a multipath volume that should have been removed with no devices or with failed or unknown devices.
In particular this occurs when a multipath device is removed during, or immediately before the call to check_path(). A missing multipath device will cause update_multipath_strings() to fail, setting pp->dmstate to PSTATE_UNDEF.
If the path is up, this state will cause reinstate_path() to be called, which will also fail. This will trigger a reload, restoring the recently removed device in an invalid state.
The command "multipathd show config" fails with "timeout receiving packet".
The command "multipath -ll" shows errors and names/paths as '#' (unexpected):
Sep 28 20:31:20 | 65:208: cannot find block device
Sep 28 20:31:20 | 65:208: Empty device name
Sep 28 20:31:20 | 65:208: Empty device name
Sep 28 20:31:20 | 65:240: cannot find block device
Sep 28 20:31:20 | 65:240: Empty device name
Sep 28 20:31:20 | 65:240: Empty device name
Sep 28 20:31:20 | 65:224: cannot find block device
Sep 28 20:31:20 | 65:224: Empty device name
Sep 28 20:31:20 | 65:224: Empty device name
Sep 28 20:31:20 | 66:0: cannot find block device
Sep 28 20:31:20 | 66:0: Empty device name
Sep 28 20:31:20 | 66:0: Empty device name
3600a098038305768462b564d48336636 dm-38 ##,##
size=19G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=0 status=enabled
| |- #:#:#:# - #:# failed undef unknown
| `- #:#:#:# - #:# failed undef unknown
`-+- policy='service-time 0' prio=0 status=enabled
|- #:#:#:# - #:# failed undef unknown
`- #:#:#:# - #:# failed undef unknown
[Test Plan]
This can be reproduced by one of our customers on a Kubernetes installation using Netapp Trident for storage orchestration.
Continuously add and remove all the individual paths for storage devices in
order to create and remove multipath devices managed by multipathd, while
checking the output of `multipath -ll`.
[Where problems could occur]
We are merging two patches here (both done by the same person on the same day).
- One just changes the return value of some functions from a boolean to symbolic codes to differentiate errors.
- The other one uses this new error codes to change the behavior of the check_path() function.
These changes mostly affect the error paths so this should not break anything
when the code works without errors, but theoretically might also affect the
normal path of periodically checking path status -- fortunaly this runs very
often, thus regressions should be easy and quick to spot during tests.
There are 2 additional upstream patches for the lines changed by these patches,
which are NULL pointer checks, and are introduced here too.
[Other Info]
Most patches only needs to be applied to Focal as it is already included in the Jammy version.
One of the additional upstream patches needs to go to Jammy and Lunar, which is
done in bug 2042366 in order to get specific/individual testing on the releases. |
[Impact]
In a server with high volume of multipath volume creation and teardown it can occur a race condition that keeps a multipath volume that should have been removed with no devices or with failed or unknown devices.
In particular this occurs when a multipath device is removed during, or immediately before the call to check_path(). A missing multipath device will cause update_multipath_strings() to fail, setting pp->dmstate to PSTATE_UNDEF.
If the path is up, this state will cause reinstate_path() to be called, which will also fail. This will trigger a reload, restoring the recently removed device in an invalid state.
The command "multipathd show config" fails with "timeout receiving packet".
The command "multipath -ll" shows errors and names/paths as '#' (unexpected):
Sep 28 20:31:20 | 65:208: cannot find block device
Sep 28 20:31:20 | 65:208: Empty device name
Sep 28 20:31:20 | 65:208: Empty device name
Sep 28 20:31:20 | 65:240: cannot find block device
Sep 28 20:31:20 | 65:240: Empty device name
Sep 28 20:31:20 | 65:240: Empty device name
Sep 28 20:31:20 | 65:224: cannot find block device
Sep 28 20:31:20 | 65:224: Empty device name
Sep 28 20:31:20 | 65:224: Empty device name
Sep 28 20:31:20 | 66:0: cannot find block device
Sep 28 20:31:20 | 66:0: Empty device name
Sep 28 20:31:20 | 66:0: Empty device name
3600a098038305768462b564d48336636 dm-38 ##,##
size=19G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=0 status=enabled
| |- #:#:#:# - #:# failed undef unknown
| `- #:#:#:# - #:# failed undef unknown
`-+- policy='service-time 0' prio=0 status=enabled
|- #:#:#:# - #:# failed undef unknown
`- #:#:#:# - #:# failed undef unknown
[Test Plan]
This can be reproduced by one of our customers on a Kubernetes installation using Netapp Trident for storage orchestration.
Continuously add and remove all the individual paths for storage devices in
order to create and remove multipath devices managed by multipathd, while
checking the output of `multipath -ll`.
[Where problems could occur]
We are merging two patches here (both done by the same person on the same day).
- One just changes the return value of some functions from a boolean to symbolic codes to differentiate errors.
- The other one uses this new error codes to change the behavior of the check_path() function.
These changes mostly affect the error paths so this should not break anything
when the code works without errors, but theoretically might also affect the
normal path of periodically checking path status -- fortunaly this runs very
often, thus regressions should be easy and quick to spot during tests.
There are 2 additional upstream patches for the lines changed by these patches,
which are NULL pointer checks, and are introduced here too.
[Other Info]
Most patches only need to be applied to Focal as they're included Jammy.
One of the additional upstream patches needs to go to Jammy and Lunar, which is
done in bug 2042366 in order to get specific/individual testing on the releases. |
|
| 2023-11-07 22:06:00 |
Mauricio Faria de Oliveira |
multipath-tools (Ubuntu Focal): status |
Incomplete |
In Progress |
|
| 2023-11-15 22:46:58 |
Robie Basak |
multipath-tools (Ubuntu Focal): status |
In Progress |
Fix Committed |
|
| 2023-11-15 22:46:59 |
Robie Basak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2023-11-15 22:47:00 |
Robie Basak |
bug |
|
|
added subscriber SRU Verification |
| 2023-11-15 22:47:03 |
Robie Basak |
tags |
|
verification-needed verification-needed-focal |
|
