Back to bug 2164871
| Who | When | What | Removed | Added |
|---|---|---|---|---|
| Red Hat Bugzilla | 2023-01-26 19:02:03 UTC | Pool ID | sst_logical_storage_rhel_8 | |
| Ben Marzinski | 2023-01-26 19:03:55 UTC | Status | NEW | ASSIGNED |
| Red Hat One Jira (issues.redhat.com) | 2023-01-26 19:05:24 UTC | Link ID | Red Hat Issue Tracker RHELPLAN-146605 | |
| Lin Li | 2023-01-28 01:58:24 UTC | CC | lilin | |
| QA Contact | storage-qe | lilin | ||
| Ben Marzinski | 2023-03-17 15:21:31 UTC | Fixed In Version | device-mapper-multipath-0.8.4-39.el8 | |
| Status | ASSIGNED | MODIFIED | ||
| Ben Marzinski | 2023-03-17 16:06:24 UTC | Doc Text | Cause: When multipathd starts up, if it found a registration key for Persistent Reservations on one path of an existing multipath device, it wasn't making sure that all paths of that device had the registration. Consequence: If new paths to a multipath device with Persistent Reservations appeared while multipathd was stopped, they would not have the Persistent Reservations set up on them and could process IO, even if they should be forbidden by a Reservation. Fix: Multipathd now makes sure to add the Persistent Reservation registration key to all paths, if it finds one on any device path. Result: Multipath devices will have Persistent Reservations set up correctly on all of their paths, even if path devices first appear while multipathd isn't running. | |
| Doc Type | If docs needed, set a value | Bug Fix | ||
| errata-xmlrpc | 2023-03-20 15:03:40 UTC | Status | MODIFIED | ON_QA |
| Lin Li | 2023-04-24 14:55:52 UTC | Status | ON_QA | VERIFIED |
| Apurva Bhide | 2023-06-22 09:44:17 UTC | CC | abhide | |
| Docs Contact | abhide | |||
| Apurva Bhide | 2023-07-10 10:33:29 UTC | Doc Text | Cause: When multipathd starts up, if it found a registration key for Persistent Reservations on one path of an existing multipath device, it wasn't making sure that all paths of that device had the registration. Consequence: If new paths to a multipath device with Persistent Reservations appeared while multipathd was stopped, they would not have the Persistent Reservations set up on them and could process IO, even if they should be forbidden by a Reservation. Fix: Multipathd now makes sure to add the Persistent Reservation registration key to all paths, if it finds one on any device path. Result: Multipath devices will have Persistent Reservations set up correctly on all of their paths, even if path devices first appear while multipathd isn't running. | .`multipathd` adds the persistent reservation registration key to all paths Previously, when the `multipathd` daemon started and it recognized a registration key for the persistent reservations on one path of an existing multipath device, it was not possible to ensure that all paths of that device had the registration key. As a consequence, if new paths to a multipath device with persistent reservations appeared while `multipathd` was stopped, persistent reservations were not set up on them and could process IO, even if they were supposed to be forbidden by the reservation key. With this fix, `multipathd` now makes sure to add the persistent reservation registration key to all paths, if it finds one on any device path. As a result, multipath devices now have persistent reservations set up correctly on all of their paths, even if path devices first appear while `multipathd` is not running. |
| Flags | needinfo?(bmarzins) | |||
| Ben Marzinski | 2023-07-10 16:50:45 UTC | Flags | needinfo?(bmarzins) | |
| Apurva Bhide | 2023-07-17 17:50:19 UTC | Flags | needinfo?(bmarzins) | |
| Doc Text | .`multipathd` adds the persistent reservation registration key to all paths Previously, when the `multipathd` daemon started and it recognized a registration key for the persistent reservations on one path of an existing multipath device, it was not possible to ensure that all paths of that device had the registration key. As a consequence, if new paths to a multipath device with persistent reservations appeared while `multipathd` was stopped, persistent reservations were not set up on them and could process IO, even if they were supposed to be forbidden by the reservation key. With this fix, `multipathd` now makes sure to add the persistent reservation registration key to all paths, if it finds one on any device path. As a result, multipath devices now have persistent reservations set up correctly on all of their paths, even if path devices first appear while `multipathd` is not running. | .`multipathd` adds the persistent reservation registration key to all paths Previously, when the `multipathd` daemon started and it recognized a registration key for the persistent reservations on one path of an existing multipath device, not all paths of that device had the registration key. As a consequence, if new paths appeared to a multipath device with persistent reservations while `multipathd` was stopped, persistent reservations were not set up on those. This allowed IO processing on the paths, even if they were supposed to be forbidden by the reservation key. With this fix, if `multipathd` finds the persistent reservation registration key on any device path, it adds the key to all path. As a result, multipath devices now have persistent reservations set up correctly on all the paths, even if path devices first appear while `multipathd` is not running. |
||
| Ben Marzinski | 2023-07-21 15:11:37 UTC | Flags | needinfo?(bmarzins) | |
| Apurva Bhide | 2023-07-28 13:56:30 UTC | Doc Text | .`multipathd` adds the persistent reservation registration key to all paths Previously, when the `multipathd` daemon started and it recognized a registration key for the persistent reservations on one path of an existing multipath device, not all paths of that device had the registration key. As a consequence, if new paths appeared to a multipath device with persistent reservations while `multipathd` was stopped, persistent reservations were not set up on those. This allowed IO processing on the paths, even if they were supposed to be forbidden by the reservation key. With this fix, if `multipathd` finds the persistent reservation registration key on any device path, it adds the key to all path. As a result, multipath devices now have persistent reservations set up correctly on all the paths, even if path devices first appear while `multipathd` is not running. | .`multipathd` adds the persistent reservation registration key to all paths Previously, when the `multipathd` daemon started and it recognized a registration key for the persistent reservations on one path of an existing multipath device, not all paths of that device had the registration key. As a consequence, if new paths appeared to a multipath device with persistent reservations while `multipathd` was stopped, persistent reservations were not set up on those. This allowed IO processing on the paths, even if they were supposed to be forbidden by the reservation key. With this fix, if `multipathd` finds a persistent reservation registration key on any device path, it adds the key to all active paths. As a result, multipath devices now have persistent reservations set up correctly on all the paths, even if path devices first appear while `multipathd` is not running. |
Back to bug 2164871