Search Criteria
Package Details: kvdo-dkms 6.2.4.26-2
Git Clone URL: | https://aur.archlinux.org/kvdo-dkms.git (read-only, click to copy) |
---|---|
Package Base: | kvdo-dkms |
Description: | A pair of kernel modules which provide pools of deduplicated and/or compressed block storage (semi-official version for latest kernels) |
Upstream URL: | https://github.com/rhawalsh/kvdo |
Licenses: | |
Provides: | |
Submitter: | zapp-brannigan |
Maintainer: | zapp-brannigan |
Last Packager: | zapp-brannigan |
Votes: | 4 |
Popularity: | 0.002055 |
First Submitted: | 2018-08-19 18:48 |
Last Updated: | 2020-12-12 08:26 |
Latest Comments
1 2 3 Next › Last »
zapp-brannigan commented on 2020-12-12 08:27
Switched to COPR repo, so everyone should be happy ;)
id01 commented on 2020-12-11 00:19
According to README.md on upstream[1], a fork compatible with new kernel versions has been made and is being maintained here[2] under the -COPR branches. While it still requires a patch for config_hz (to remove the check for an integer number of millseconds in every tick), it no longer needs vla-warning, and can compile on latest kernels.
I suggest using this, and have made an alternate version of this PKGBUILD using those sources that works on 5.9.
[1] https://github.com/dm-vdo/kvdo
[2] https://github.com/rhawalsh/kvdo/tree/6.2.4.26-COPR
PKGBUILD:
config_hz.patch:
mushrewm commented on 2020-05-12 02:40
I made a patch[1] to this repo to get it building again on the latest kernels.
[1] https://gist.github.com/SeamusConnor/90394a58cdc1d30c396a1c43f206768e
zapp-brannigan commented on 2020-04-15 16:35
I guess they will fix it upstream. Meanwhile i suggest you to use linux-lts.
dsoul commented on 2020-04-15 06:21
Please add patches for kernel 5.6
https://github.com/dm-vdo/kvdo/issues/29#issuecomment-592686755
zapp-brannigan commented on 2020-03-13 18:37
Kernelswitching is a good point, hadn't that in mind. With the next upstreamrelease i will apply the patch unconditionally.
jgottula commented on 2020-03-12 23:45
@zapp-brannigan Thanks for integrating that! It works great, though with a caveat:
You're conditionally applying the patch and printing the warning in the PKGBUILD
package()
function based on the config of whichever kernel is running at the time of packaging. And because this is a DKMS package, one copy of the source code is installed in /usr/src/, which is then later compiled for potentially all the different kernels that a user may have installed on their system.So, as an example, if a user happens to have booted with linux-lts and builds the package at that time, then they won't get the warning message, and the module source code installed to the system won't have the patch. So if that user also has stock linux installed and decides to reboot into that, they won't have a working kvdo module: the DKMS build for that kernel will fail / have failed.
The best course of action, I think, would be to apply the patch unconditionally (seeing as it has no effect on the other
CONFIG_HZ
values anyway). And then maybe see if there's an easy way to move the warning message into the DKMS config file, or perhaps one of the Makefiles, or something like that, such that it gets printed at the time ofdkms build
/dkms install
. (Or maybe just leave the warning inpackage()
, print it unconditionally, and trust that users will take note of it if they believe it concerns their setup.)But anyway. For the simple case of always booting with the stock linux kernel, and running the
makepkg
for this while running under that kernel, the package does currently do basically the right thing.zapp-brannigan commented on 2020-03-12 17:43
Updated the pkgbuild. @jgottula maybe you can test it (i'm on linux-lts...)?
jgottula commented on 2020-03-11 21:43
The build problem with the stock Arch Linux kernel is 100% due to the stock Arch kernel config using
CONFIG_HZ=300
.This kernel module currently does some timing calculations (for histograms etc) assuming on an integer number of jiffies-per-millisecond (i.e. ticks per millisecond)... and it just so happens that 1000 does not divide evenly by 300. (
CONFIG_HZ=100
,=250
,=1000
are all fine because those do divide evenly: 10, 4, 1 jiffies-per-ms respectively.)In the upstream bug thread regarding this exact problem, it's mentioned that this is a temporary limitation that should be fixed in an upcoming version, hopefully relatively soon. (And in fact, there are also a few places in the code itself where it's mentioned that an assumption is being made which won't necessarily be true for all kernel configs, and that that needs to be fixed up.)
In addition, that thread provides a recommended workaround for the build failure: simply remove or comment-out the
STATIC_ASSERT((MSEC_PER_SEC % HZ) == 0);
line (vdo/kernel/histogram.c:600), and then the module will no longer fail to build againstCONFIG_HZ=300
kernels. With this workaround, the histogram and timing stats will be slightly skewed onCONFIG_HZ=300
kernels: the calculations will assume that tick intervals are 4ms long, rather than the actual 3.33ms, since thejiffies_to_msecs
function in the kernel rounds up when a strictly-integral division result isn't possible. But the real core functionality of the kernel module won't be adversely affected at all.Given the above, I'd suggest that the best course of action for now (until the upstream devs get around to fixing their integer problem) would be to add a patch to this package that implements the workaround described above (i.e. removing the problematic
STATIC_ASSERT
line). Then, at least users of the stock Arch kernel (or any other kernel withCONFIG_HZ=300
set, for that matter) will be able to actually build and use this package (albeit with a 20% inflation of the reported timing stats relative to what they should be, due to the 4ms-vs-3.33ms discrepancy). And then, when the upstream devs do finally decide to fix their code, we can ditch the patch at that point.(Maybe we could even throw in a warning message as the package builds to inform the user about the side-effect on the reported timings they will get if they are building for a
CONFIG_HZ=300
kernel, if we wanted to be super-duper-thorough.)Thoughts? @zapp-brannigan
danhyal commented on 2020-01-01 20:48
I'm 99% sure it's related to the CONFIG_HZ kernel config, to fix the build issue compile linux-ck with CONFIG_HZ=1000 or use linux-zen where it is the default.