Package Details: kvdo-dkms

Git Clone URL: (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
Upstream URL:
Licenses: GPL2
Provides: kvdo
Submitter: zapp-brannigan
Maintainer: eggz
Last Packager: eggz
Votes: 3
Popularity: 0.000000
First Submitted: 2018-08-19 18:48 (UTC)
Last Updated: 2022-07-31 10:10 (UTC)

Dependencies (0)

Required by (1)

Sources (2)

Pinned Comments

eggz commented on 2022-01-27 13:04 (UTC)

Tired of compiling? Use this binary repo instead! Add this at the end of /etc/pacman.conf :

Server =$repo/$arch
SigLevel = Optional TrustAll

Latest Comments

eggz commented on 2022-01-27 13:16 (UTC)

Hello guys, I have adopted this package to make it work with the latest kernel. For my environment it seems to work now, I can get started.

But I cannot guarantee it will work for other environments aswell. If it proves too much work then ill probably end up orphaning these vdo packages aswel. Its just that ... I got it working for me and I just wanted to share my work.

eggz commented on 2022-01-27 13:04 (UTC)

Tired of compiling? Use this binary repo instead! Add this at the end of /etc/pacman.conf :

Server =$repo/$arch
SigLevel = Optional TrustAll

zork commented on 2022-01-27 13:03 (UTC)

8.x is not production ready. vdo python tool do not exists anymore, there is no easy way to convert existing non-lvm devices to vdo-lvm devices, documentation is not complete [1].

I managed to compile it with 5.15 using, but I reverted back to 5.4 kernel from kernel-lts unofficial repo and the latest kvdo 6.x


zapp-brannigan commented on 2021-03-26 15:20 (UTC)

Hmmm, i see. Since i do not use vdo/kvdo anymore, is anybody interested to take over maintenance for the PKGBUILDs?

nyoxi commented on 2021-03-26 12:08 (UTC)

Unfortunately no. :) The source now point to a git branch and not to a tagged commit. Since there were new commits pushed in February the SHA has does not match anymore.

The following patch makes it explicit that git branch is used to avoid confusion. Optionally appending string "-git" to VERSION or something like that may be be a good idea too.

diff --git a/PKGBUILD b/PKGBUILD
index af6cf68..645646c 100644
@@ -10,16 +10,16 @@ arch=('x86_64')

 package() {
   mkdir -p "$pkgdir"/usr/src
-  cp -r "$_pkgname-$pkgver-COPR" "$pkgdir"/usr/src/"$_pkgname-$pkgver"
+  cp -r "$_pkgname" "$pkgdir"/usr/src/"$_pkgname-$pkgver"
   cd "$pkgdir"/usr/src/kvdo-"$pkgver"
   patch --forward --strip=0 -i "$srcdir"/config_hz.patch
   cd "$srcdir"

zapp-brannigan commented on 2020-12-12 08:27 (UTC)

Switched to COPR repo, so everyone should be happy ;)

id01 commented on 2020-12-11 00:19 (UTC) (edited on 2020-12-11 00:20 (UTC) by id01)

According to 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.




# Maintainer: zapp-brannigan <>
#             danhyal <>
#             jgottula
pkgdesc='A pair of kernel modules which provide pools of deduplicated and/or compressed block storage'

package() {
  mkdir -p "$pkgdir"/usr/src
  cp -r "$_pkgname-$pkgver-COPR" "$pkgdir"/usr/src/"$_pkgname-$pkgver-COPR"
  cd "$pkgdir"/usr/src/kvdo-"$pkgver-COPR"
  patch --forward --strip=0 -i "$srcdir"/config_hz.patch
  cd "$srcdir"
  sed -e "s/@PKGVER@/${pkgver}-COPR/" dkms.conf > "$pkgdir"/usr/src/"$_pkgname-$pkgver-COPR"/dkms.conf


--- vdo/kernel/histogram.c  2020-12-10 15:44:20.579469737 -0800
+++ vdo/kernel/histogram.c  2020-12-10 15:44:36.982834361 -0800
@@ -595,8 +595,10 @@
    * If these fail, we have a jiffy duration that is not an integral number of
    * milliseconds, and the unit conversion code needs updating.
+/* I live on the edge
   return makeLogarithmicHistogramWithConversionFactor(parent, name, initLabel,
                                                       metric, "milliseconds",

mushrewm commented on 2020-05-12 02:40 (UTC)

I made a patch[1] to this repo to get it building again on the latest kernels.


zapp-brannigan commented on 2020-04-15 16:35 (UTC)

I guess they will fix it upstream. Meanwhile i suggest you to use linux-lts.

dsoul commented on 2020-04-15 06:21 (UTC)

Please add patches for kernel 5.6

zapp-brannigan commented on 2020-03-13 18:37 (UTC)

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 (UTC)

@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 of dkms build / dkms install. (Or maybe just leave the warning in package(), 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 (UTC)

Updated the pkgbuild. @jgottula maybe you can test it (i'm on linux-lts...)?

jgottula commented on 2020-03-11 21:43 (UTC)

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 against CONFIG_HZ=300 kernels. With this workaround, the histogram and timing stats will be slightly skewed on CONFIG_HZ=300 kernels: the calculations will assume that tick intervals are 4ms long, rather than the actual 3.33ms, since the jiffies_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 with CONFIG_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

amelia commented on 2020-01-01 20:48 (UTC)

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.

damir commented on 2020-01-01 20:21 (UTC)

but it builds fine against 4.19.92-1-lts (my backup kernel) ;)

damir commented on 2020-01-01 20:21 (UTC)

i just ran into another problem against kernel 5.4.7-arch1-1 (x86_64):

  LD [M]  /var/lib/dkms/kvdo/
In file included from /var/lib/dkms/kvdo/,
                 from /var/lib/dkms/kvdo/
/var/lib/dkms/kvdo/ In function ‘makeLogarithmicJiffiesHistogram’:
/var/lib/dkms/kvdo/ error: duplicate case value
  114 |     case expr:              \
      |     ^~~~
/var/lib/dkms/kvdo/ note: in expansion of macro ‘STATIC_ASSERT’
  600 |   STATIC_ASSERT((MSEC_PER_SEC % HZ) == 0);
      |   ^~~~~~~~~~~~~
/var/lib/dkms/kvdo/ note: previously used here
  113 |     case 0:                 \
      |     ^~~~
/var/lib/dkms/kvdo/ note: in expansion of macro ‘STATIC_ASSERT’
  600 |   STATIC_ASSERT((MSEC_PER_SEC % HZ) == 0);
      |   ^~~~~~~~~~~~~
make[2]: *** [scripts/ /var/lib/dkms/kvdo/] Error 1

damir commented on 2020-01-01 20:20 (UTC)

linux-ck-zen is from

amelia commented on 2020-01-01 16:43 (UTC)

@damir I don't see a kernel called linux-ck-zen on the aur, have you tried the linux-zen kernel? that works just fine for me.

damir commented on 2020-01-01 16:32 (UTC)

FYI - kvdo is not compatible with linux-ck-zen:

  CC [M]  /var/lib/dkms/kvdo/
/var/lib/dkms/kvdo/ In function ‘a
/var/lib/dkms/kvdo/ error: ‘
struct task_struct’ has no member named ‘se’
   69 |     .cputime  = task->se.sum_exec_runtime,
      |                     ^~
  CC [M]  /var/lib/dkms/kvdo/
make[2]: *** [scripts/ /var/lib/dkms/kvdo/
resourceUsageLinuxKernel.o] Error 1

zapp-brannigan commented on 2019-12-21 08:08 (UTC)

Thank you, merged your changes :)

amelia commented on 2019-12-21 02:10 (UTC)

I have fixed the package using a patch from upstream, consider merging the changes from my repo.

balwierz commented on 2019-07-27 09:53 (UTC) (edited on 2019-07-27 09:54 (UTC) by balwierz)

Module does not compile with the current gcc + kernel sources:

/var/lib/dkms/kvdo/ In function ‘swapElements’:
/var/lib/dkms/kvdo/ error: ISO C90 forbids variable length array ‘temp’ [-Werror=vla]
   52 |   byte temp[heap->elementSize];
      |   ^~~~
cc1: all warnings being treated as errors
make[2]: *** [scripts/ /var/lib/dkms/kvdo/] Error 1
make[2]: *** Waiting for unfinished jobs....
/var/lib/dkms/kvdo/ In function ‘initializePathBufferSprintf’:
/var/lib/dkms/kvdo/ error: ISO C90 forbids array ‘buf’ whose size can’t be evaluated [-Werror=vla]
   91 |   char buf[DEFAULT_PATH_BUFFER_SIZE];
      |   ^~~~
cc1: all warnings being treated as errors

nyoxi commented on 2019-02-28 19:24 (UTC)

I see. linux-lts has HZ set to 100, that's why the assert works there.

zapp-brannigan commented on 2019-02-19 19:56 (UTC)

It works with linux-lts (or any kernel below 4.20) for now. As you already noticed, the module is broken with kernel 4.20. I hope they will update their sources soon.

nyoxi commented on 2019-02-19 19:38 (UTC)

Build fails with current kernel because of [1]. But that is fixable [2].

More importantly, build fails on this assert [3]: STATIC_ASSERT((MSEC_PER_SEC % HZ) == 0);

MSEC_PER_SEC is 1000 and HZ is 300 on Arch kernels. Which makes me wonder, has this module ever worked with stock Arch kernel?

[1] [2] [3]