Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

plug and play currently requires systemctl restart target #19

Open
omac777 opened this issue Oct 30, 2015 · 1 comment
Open

plug and play currently requires systemctl restart target #19

omac777 opened this issue Oct 30, 2015 · 1 comment

Comments

@omac777
Copy link

omac777 commented Oct 30, 2015

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.

@tramjoe
Copy link
Contributor

tramjoe commented Nov 2, 2015

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)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants