Hi Guys, looks like Nick Wang (drbd maintainer) isn't active anymore. Do we have a plan, how to maintain the drbd stuff, specifically the kernel module. Before I wrote this, I looked into it of course, but failed (wouldn't write this mail otherwise..). This coccinelle stuff scares me to death. Needless to say, drbd-kmod doesn't build anymore since the release of kernel 5.18. Best, Pete -- Life without chameleons is possible, but pointless.
On Fri, Jun 24, 2022 at 12:50 PM Hans-Peter Jansen <hpj@urpla.net> wrote:
Hi Guys,
looks like Nick Wang (drbd maintainer) isn't active anymore.
Do we have a plan, how to maintain the drbd stuff, specifically the kernel module. Before I wrote this, I looked into it of course, but failed (wouldn't write this mail otherwise..).
This coccinelle stuff scares me to death.
Needless to say, drbd-kmod doesn't build anymore since the release of kernel 5.18.
E-h-h ... drbd driver is part of the upstream kernel (drivers/block/drbd). What's wrong with the in-tree driver and why a separate external module is needed?
-- Best, Pete -- Life without chameleons is possible, but pointless. Am Freitag, 24. Juni 2022, 12:40:32 CEST schrieb Andrei Borzenkov:
On Fri, Jun 24, 2022 at 12:50 PM Hans-Peter Jansen <hpj@urpla.net> wrote:
Hi Guys,
looks like Nick Wang (drbd maintainer) isn't active anymore.
Do we have a plan, how to maintain the drbd stuff, specifically the kernel module. Before I wrote this, I looked into it of course, but failed (wouldn't write this mail otherwise..).
This coccinelle stuff scares me to death.
Needless to say, drbd-kmod doesn't build anymore since the release of kernel 5.18.
E-h-h ... drbd driver is part of the upstream kernel (drivers/block/drbd). What's wrong with the in-tree driver and why a separate external module is needed?
Ahh, good point Andrei, thanks. Probably because: $ zyp in drbd-utils [...] The following 3 NEW packages are going to be installed: drbd 9.0.30~1+git.8e9c0812-19.75 drbd-kmp-preempt 9.0.30~1+git.8e9c0812_k5.17.9_2-19.75 drbd-utils 9.19.0-3.5 Question is, why does drdb-utils insists in depending on drbd? $ rpm -ql drbd /usr/sbin/rcdrbd /usr/share/doc/packages/drbd /usr/share/doc/packages/drbd/ChangeLog /usr/share/licenses/drbd /usr/share/licenses/drbd/COPYING Arghh, it contains a system v5 init script adapted to systemd to do what? $ sc status drbd ● drbd.service - DRBD -- please disable. Unless you are NOT using a cluster manager. Loaded: loaded (/usr/lib/systemd/system/drbd.service; disabled; vendor preset: disabled) Active: inactive (dead) Oh, well. Any idea how to proceed? Best, Pete
On 24.06.2022 16:13, Hans-Peter Jansen wrote:
On Fri, Jun 24, 2022 at 12:50 PM Hans-Peter Jansen <hpj@urpla.net> wrote:
Hi Guys,
looks like Nick Wang (drbd maintainer) isn't active anymore.
Do we have a plan, how to maintain the drbd stuff, specifically the kernel module. Before I wrote this, I looked into it of course, but failed (wouldn't write this mail otherwise..).
This coccinelle stuff scares me to death.
Needless to say, drbd-kmod doesn't build anymore since the release of kernel 5.18. E-h-h ... drbd driver is part of the upstream kernel (drivers/block/drbd). What's wrong with the in-tree driver and why a separate external module is needed? Ahh, good point Andrei, thanks. Probably because:
$ zyp in drbd-utils [...] The following 3 NEW packages are going to be installed: drbd 9.0.30~1+git.8e9c0812-19.75 drbd-kmp-preempt 9.0.30~1+git.8e9c0812_k5.17.9_2-19.75 drbd-utils 9.19.0-3.5
it is soft dependency, you can lock it if you like Supplements : (kernel-default and drbd) I cannot comment whether in-tree module is suitable as replacement for Linbit version.
Question is, why does drdb-utils insists in depending on drbd?
$ rpm -ql drbd /usr/sbin/rcdrbd /usr/share/doc/packages/drbd /usr/share/doc/packages/drbd/ChangeLog /usr/share/licenses/drbd /usr/share/licenses/drbd/COPYING
Arghh, it contains a system v5 init script adapted to systemd to do what?
$ sc status drbd ● drbd.service - DRBD -- please disable. Unless you are NOT using a cluster manager. Loaded: loaded (/usr/lib/systemd/system/drbd.service; disabled; vendor preset: disabled) Active: inactive (dead)
Oh, well.
Any idea how to proceed?
Best, Pete
On 6/24/22 12:40, Andrei Borzenkov wrote:
On Fri, Jun 24, 2022 at 12:50 PM Hans-Peter Jansen <hpj@urpla.net> wrote:
Hi Guys,
looks like Nick Wang (drbd maintainer) isn't active anymore.
Do we have a plan, how to maintain the drbd stuff, specifically the kernel module. Before I wrote this, I looked into it of course, but failed (wouldn't write this mail otherwise..).
This coccinelle stuff scares me to death.
Needless to say, drbd-kmod doesn't build anymore since the release of kernel 5.18.
E-h-h ... drbd driver is part of the upstream kernel (drivers/block/drbd). What's wrong with the in-tree driver and why a separate external module is needed?
Because Linbit is developing the DRBD driver outside the kernel, and it has diverged quite heavily from the in-kernel one. And having far more features to boot. So just falling back to the in-kernel one is not making you any friends, especially not with existing installations. Cheers, Hannes
On 6/24/22 08:43, Hannes Reinecke wrote:
Because Linbit is developing the DRBD driver outside the kernel, and it has diverged quite heavily from the in-kernel one. And having far more features to boot.
So just falling back to the in-kernel one is not making you any friends, especially not with existing installations.
Doing development outside the kernel for a driver already included in the kernel is absolutely the wrong thing to do! To me, this situation reeks of developer(s) getting bad reviews and forking the code into a separate project rather than doing the hard work of fixing the problem. As an example, look at the history of the Reiser 4 file system, which was derived from reiserfs! This behavior should not be rewarded by openSUSE. For maximum security, someone should update the in-kernel version following the standard patch submission and review procedures. As maintainer of the openSUSE version of VirtualBox, I am fully aware of the hazards of out-of-kernel drivers with lots of security holes. VB gets many, many CVE fixes each year. In this case, the value of the package warrants the use of VB; however, I would be pleased if Oracle decided to rework the code and submit it to the kernel. A lot of my work would disappear if the authors of API changes had to fix the breakage of the VB drivers. Larry
On 6/24/22 16:23, Larry Finger wrote:
On 6/24/22 08:43, Hannes Reinecke wrote:
Because Linbit is developing the DRBD driver outside the kernel, and it has diverged quite heavily from the in-kernel one. And having far more features to boot.
So just falling back to the in-kernel one is not making you any friends, especially not with existing installations.
Doing development outside the kernel for a driver already included in the kernel is absolutely the wrong thing to do!
To me, this situation reeks of developer(s) getting bad reviews and forking the code into a separate project rather than doing the hard work of fixing the problem. As an example, look at the history of the Reiser 4 file system, which was derived from reiserfs! This behavior should not be rewarded by openSUSE. For maximum security, someone should update the in-kernel version following the standard patch submission and review procedures.
Wrong tree to bark on. I've expressed the very same sentiments to Phil Reisner and Linbit. Unfortunately by now both trees have diverged significantly such that it's a major effort to reconcile / update the in-kernel sources. Cheers, Hannes
On 24.06.2022 18:05, Hannes Reinecke wrote:
On 6/24/22 16:23, Larry Finger wrote:
On 6/24/22 08:43, Hannes Reinecke wrote:
Because Linbit is developing the DRBD driver outside the kernel, and it has diverged quite heavily from the in-kernel one. And having far more features to boot.
So just falling back to the in-kernel one is not making you any friends, especially not with existing installations.
Doing development outside the kernel for a driver already included in the kernel is absolutely the wrong thing to do!
To me, this situation reeks of developer(s) getting bad reviews and forking the code into a separate project rather than doing the hard work of fixing the problem. As an example, look at the history of the Reiser 4 file system, which was derived from reiserfs! This behavior should not be rewarded by openSUSE. For maximum security, someone should update the in-kernel version following the standard patch submission and review procedures.
Wrong tree to bark on.
I've expressed the very same sentiments to Phil Reisner and Linbit. Unfortunately by now both trees have diverged significantly such that it's a major effort to reconcile / update the in-kernel sources.
Should not drbd module be removed from kernel-default then? It is not present on Leap 15.4 as example but is present on Tumbleweed. Otherwise it is possible to use in-tree version instead of Linbit version.
Am Freitag, 24. Juni 2022, 17:09:46 CEST schrieb Andrei Borzenkov:
Should not drbd module be removed from kernel-default then? It is not present on Leap 15.4 as example but is present on Tumbleweed. Otherwise it is possible to use in-tree version instead of Linbit version.
To be honest, I'm using drbd for exact one thing: low level mounting a qemu disk image (e.g., when I need full disk access to an qcow2 image). guestmount only provides fs centered access to my knowledge. What about using the in kernel drbd with TW, and leave the LINBIT drbd maintenance to those, that rely on its enterprise features. Unlike Larry, who is always ahead of time and a pleasure to work with, Nick mostly required a PING in order to notice drbd build failures with new kernel releases... Out of curiosity, I applied my casual work scheme: adjust _service, remove the failing patches, and check, if I can make any sense out of the appearing build failures. Tried all branches: 9.0, 9.1 and master, but they all fail in similar ways. What a mess. Best, Pete -- Life without chameleons is possible, but pointless.
On Sat, 25 Jun 2022, Hans-Peter Jansen wrote:
Am Freitag, 24. Juni 2022, 17:09:46 CEST schrieb Andrei Borzenkov:
Should not drbd module be removed from kernel-default then? It is not present on Leap 15.4 as example but is present on Tumbleweed. Otherwise it is possible to use in-tree version instead of Linbit version.
To be honest, I'm using drbd for exact one thing: low level mounting a qemu disk image (e.g., when I need full disk access to an qcow2 image).
IMHO using nbd is easier for this, have you considered it? % modprobe nbd % qemu-nbd --connect /dev/nbd0 file.qcow2 % fdisk -l /dev/nbd0 % mount /dev/nbd0p1 /mnt % umont /mnt % qemu-nbd --disconnect /dev/nbd0 % rmmod nbd Ciao, Michael.
Am Montag, 27. Juni 2022, 17:36:00 CEST schrieb Michael Matz:
On Sat, 25 Jun 2022, Hans-Peter Jansen wrote:
Am Freitag, 24. Juni 2022, 17:09:46 CEST schrieb Andrei Borzenkov:
Should not drbd module be removed from kernel-default then? It is not present on Leap 15.4 as example but is present on Tumbleweed. Otherwise it is possible to use in-tree version instead of Linbit version.
To be honest, I'm using drbd for exact one thing: low level mounting a qemu disk image (e.g., when I need full disk access to an qcow2 image).
IMHO using nbd is easier for this, have you considered it?
% modprobe nbd % qemu-nbd --connect /dev/nbd0 file.qcow2 % fdisk -l /dev/nbd0 % mount /dev/nbd0p1 /mnt % umont /mnt % qemu-nbd --disconnect /dev/nbd0 % rmmod nbd
This is exactly the procedure, I'm using already. <Duuh> Obviously, I mixed up nbd and drbd. Pffft. Will be a pleasure for me to eliminate drbd from my bouquet of relevant kernel modules. Thanks for making me aware of this, Michael. Best, Pete -- Life without chameleons is possible, but pointless.
participants (5)
-
Andrei Borzenkov -
Hannes Reinecke -
Hans-Peter Jansen -
Larry Finger -
Michael Matz