You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I physically disconnected a defective device, then connected a new device the same slot.
When going back to the client(initiator) side, the drive is not there.
After systemctl restart target, the drive appeared on the client(initiator) side.
The issue I have with this is is implies not having access to other drives while restarting the target.
Is that the currently accepted practice for dealing with this situation with targetcli?
Thank you.
The text was updated successfully, but these errors were encountered:
Hi. This is not really a behavior that is dependent on targetcli itself, but is the way the kernel-side reacts to the suppression of a device.
However, this is something that could be fixed from userspace if we had a daemon managing that sort of thing, but neither rtslib nor targetcli are built to do it. There is currently no userspace daemon that handles these tasks, and am not convinced that there should be one by default.
You could bring it up on the lkml list for target-devel and seek comments there.
By the way, I am not sure that you actually need to restart the whole config. Have you tried resetting only the backend device and corresponding LUN(s)?
I physically disconnected a defective device, then connected a new device the same slot.
When going back to the client(initiator) side, the drive is not there.
After systemctl restart target, the drive appeared on the client(initiator) side.
The issue I have with this is is implies not having access to other drives while restarting the target.
Is that the currently accepted practice for dealing with this situation with targetcli?
Thank you.
The text was updated successfully, but these errors were encountered: