NAS-115860 / 22.12 / fix importing zpools on SCALE #8972
Merged
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
bugclerk
changed the title
…according to PEP8" This reverts commit 8091d14.
sonicaj
reviewed
May 17, 2022
sonicaj
reviewed
May 17, 2022
sonicaj
approved these changes
May 17, 2022
That's a valid point, let me make sure |
|
retest this please |
|
Also why is this a script outside of middleware? |
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.
Discovered and witnessed on an internal M50 (no expansion shelf) as well as an R50b with an ES60 expansion shelf (in the field). The simplified version is that
/dev/disk/by-partuuidsymlinks aren't being created by the time the raw devices are being populated inside/dev/.Since we're trying to import the zpools specifying
/dev/disk/by-partuuidAND/dev/it means zpool is importing the disks via gptid but if it can't find one, it's choosing a random raw device. The device letters for raw devices aren't guaranteed between reboots and often change so when the zpool is imported, certain devices are "missing" and other drives are being put in their place.This is painful because the zpool is now imported and in an unhealthy state. This adds a simple helper script that gets called as a prerequisite to the
ExecStartentries in theix-zfs.servicefile. Testing this on the M50, fixed the problem and the zpool imported with gptid's and produced a healthy pool.NOTE: This is still "flawed" and not something that I want to do but our hand is forced. The "proper" solution is for openzfs to actually integrate with systemd and use the proper mechanism(s) to automagically handle this.
The
ix-zfs.servicehas a time limit of 15mins while we allow udev "events" to be received for a maximum of 10mins. This worked on the R50b and the M50 so I'm leaving those time limits for now.BONUS: adding
After=systemd-udevd-settle.serviceis what I initially thought would be the "solution" but that emits a DeprecationWarning from systemd. Furthermore, reading the documentation uses big scary verbiage about how this is absolutely the wrong approach, so I've refrained from doing that.