-
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
dracut mangles the spl_hostid parameter #399
Milestone
Comments
dajhorn do you have any objections to me moving the openzfs/spl@79593b0 change from the spl %post in to the zfs dracut/90zfs/module-setup.sh script. This needs to be done to resolve issue described in comment #98. I can update parse-zfs.sh as described in this issue while I'm at it. |
No objections. |
kernelOfTruth
pushed a commit
to kernelOfTruth/zfs
that referenced
this issue
Mar 1, 2015
New versions of dkms clean up the build directory after installing. It appears that this was always intended, but had rm -rf "/path/to/build/*" (note the quotes), which prevented it from working. Also, the build step is already installing stuff into the directory where these files go, so installing our stuff there as part of build rather than install makes sense. Signed-off-by: Tom Prince <[email protected]> Signed-off-by: Richard Yao <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes openzfs#399
ahrens
added a commit
to ahrens/zfs
that referenced
this issue
Aug 17, 2021
…objects (openzfs#399) When the kernel crashes in the middle of a txg, there may be some new objects that were created, but which are not part of the consistent state yet (i.e. the last uberblock does not reference them). When opening a pool, we need to look for and remove these "leaked" objects. The leaking is actually not a big deal, because it's not a lot of space and we're going to overwrite (most of) these objects soon anyway. However, if these "leaked" objects are present during agent recovery (i.e. agent dies and comes back during a txg), it can confuse the recovery process because we can't tell which "extra" objects are "leaked", useless objects, written by the crashed kernel, vs which are "recovered", useful objects that were written by this instance of the kernel. This leads to incorrect recovery. The solution is to proactively clean up the "leaked" objects when opening the pool. This includes objects that contain DataObjectPhys and ObjectBasedLogChunk.
sdimitro
pushed a commit
to sdimitro/zfs
that referenced
this issue
May 23, 2022
Use the new `watch::Receiver::same_channel()` method so that we don't need an Arc for every in-progress async_cache load (i.e. GET from object store).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
dracut/90zfs/parse-zfs.sh
incorrectly sets the/etc/hostid
file like this:This is incorrect because
/etc/hostid
is a binary file and the${spl_hostid}
kernel parameter is usually a hexadecimal string.Currently, if
spl_hostid=0x12345678
is set as a kernel parameter, then the module gets $spl_hostid[2..3], which is only eight bits of actual uniqueness. It follows that the value cannot be reversed for comparison against a generated gethostid() result, which could cause side-effects for issue #398.The scripting contortion in commit openzfs/spl@79593b0 is required for all 32-bits of the value to be usable.
The text was updated successfully, but these errors were encountered: