-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
zfs create -V
should wait for udev
#7875
Comments
There are a few cases in addition to zfs create that could result in interaction with udev and creation of device nodes, e.g. zfs recv and zpool import. It would also be nice to address similar issues with destruction of device nodes that occurs as a result of zfs destroy and zpool export. |
It looks like only root can listen for udev events. Does ZoL support, or plan on someday supporting, delegating the ability to create volumes? If non-root users can create volumes, that would make using libudev trickier. |
@jgallag88 #7381 "[WIP] Permit ZVOL creation by unprivileged users" |
That's definitely a possibility as @loli10K mentioned.
@jgallag88 I'm pretty sure that isn't the case, at least on CentOS 7. You can see this for yourself by running
|
This issue has been automatically marked as "stale" because it has not had any activity for a while. It will be closed in 90 days if no further activity occurs. Thank you for your contributions. |
System information
Describe the problem you're observing
Creation of the
/dev/
device file for a volume is handled asynchronously on Linux by udev. This means that it's possible for thezfs create -V
to return before udev has populated/dev/
with the required entry. This behavior complicates scripting since the caller is responsible for waiting on udev.The proposed solution is to update
zfs create -V
to uselibudev
to block until udev has completed and created the entry. This should be the default behavior, and we should provide a way to request the asynchronous behavior for callers which can take advantage of it.Describe how to reproduce the problem
See issue #7863
The text was updated successfully, but these errors were encountered: