Call udevadm trigger more safely #184
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Some udev hooks are not designed to be idempotent, so calling udevadm trigger outside of the distribution's initialization scripts can have unexpected (and potentially dangerous) side effects. For example, the system time may change or devices may appear multiple times. See Ubuntu launchpad bug 320200 and this mailing list post for more details: https://lists.ubuntu.com/archives/ubuntu-devel/2009-January/027260.html To avoid these problems we call udevadm trigger with --action=change --subsystem-match=block. The first argument tells udev just to refresh devices, and make sure everything's as it should be. The second argument limits the scope to block devices, so devices belonging to other subsystems cannot be affected. This doesn't fix the problem on older udev implementations that don't provide udevadm but instead have udevtrigger as a standalone program. In this case the above options aren't available so there's no way to call call udevtrigger safely. But we can live with that since this issue only exists in optional test and helper scripts, and most zfs-on-linux users are running newer systems anyways.
|
Commit fa417e5 cherry-picked and applied to master. Closing pull request. |
prateekpandey14
pushed a commit
to prateekpandey14/zfs
that referenced
this pull request
Mar 13, 2019
When replica gets disconnected with target due to timeout, there might be some IOs that are not responded for long time. There are ZIO delay logs that helps in debugging this issue. This PR is to logs at uZFS layer regarding high latent IOs. Signed-off-by: Vishnu Itta <[email protected]>
mmaybee
pushed a commit
to mmaybee/openzfs
that referenced
this pull request
Apr 6, 2022
Add a tunable which enables reading blocks from S3 by getting first the DataObject header, and then just the block we are looking for. Disabled by default but shows that this works. In the future we can figure out when it would be a net performance benefit to do this. Gets around 5x more random blocks per second, while consuming 1/10th the network bandwidth and 2/3 the CPU (requires S3 queue depth=300).
mmaybee
pushed a commit
to mmaybee/openzfs
that referenced
this pull request
Apr 6, 2022
The tunable added by openzfs#184 should have used the new `tunable!` macro.
arter97
pushed a commit
to arter97/zfs
that referenced
this pull request
Nov 23, 2023
NAS-125230 / 23.10 / Auto-generate changelog during configure
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Some udev hooks are not designed to be idempotent, so calling udevadm
trigger outside of the distribution's initialization scripts can have
unexpected (and potentially dangerous) side effects. For example, the
system time may change or devices may appear multiple times. See Ubuntu
launchpad bug 320200 and this mailing list post for more details:
https://lists.ubuntu.com/archives/ubuntu-devel/2009-January/027260.html
To avoid these problems we call udevadm trigger with --action=change
--subsystem-match=block. The first argument tells udev just to refresh
devices, and make sure everything's as it should be. The second
argument limits the scope to block devices, so devices belonging to
other subsystems cannot be affected.
This doesn't fix the problem on older udev implementations that don't
provide udevadm but instead have udevtrigger as a standalone program.
In this case the above options aren't available so there's no way to
call call udevtrigger safely. But we can live with that since this
issue only exists in optional test and helper scripts, and most
zfs-on-linux users are running newer systems anyways.