Standalone backup agents for Linux and Unix workloads on-premises or in the public cloud
Locked
jandrewartha
Influencer
Posts: 23
Liked: 2 times
Joined: Feb 13, 2017 1:49 am
Contact:

Veeam for linux 5.8

Post by jandrewartha »

I had a look at the patch Veeam submitted to the kernel, which is here https://lkml.org/lkml/2020/8/27/1266 and naturally the kernel developers told them to go away because they don't add features to support out-of-tree modules. Reading the patch series that caused the problem, https://lore.kernel.org/lkml/2020070108 ... ch@lst.de/ and https://lore.kernel.org/lkml/2020070108 ... ch@lst.de/ it seems like make_request_fn was renamed submit_bio and relocated into block_device_operations which is const so can't be hooked.

So I guess the question is why doesn't Veeam upstream its module, since it is GPLv2 licensed?

Ejdesgaard
Service Provider
Posts: 37
Liked: 6 times
Joined: Aug 24, 2012 11:59 am
Contact:

Re: Veeam for linux 5.8

Post by Ejdesgaard »

Hello,
@jandrewartha Thanks for linking to the relevant information that @Gostev managed to forget in the weekly newsletter...

First things first, this should not be taken as me trying to be rude, but rather trying to explain, what I see being the problem and how it can be solved.

I'm afraid that the core of the issue is that core @Veeam employees does not grasp how the Linux eco-system works, as is also indicated in the conversation in veeam-agents-for-linux-unix-f41/veeam-s ... 67143.html
The fact that @Gostev is ranting about the way Linux works in the newsletter, send out 3 days AFTER a firm statement from the relevant maintainer, that makes it crystal clear that if you want to add complexity to the Linux kernel, there must be a proper use-case for a component in the Linux kernel, which of there is not at the moment, because the veeamsnap module is not part of the kernel.
This further confirms a lack of understanding of how the Linux eco-system works, from within relevant department(s) @Veeam.


@Gostev, @PTide and everyone else @VEEAM:
If Veeam want's to support Linux, then Veeam needs to "play ball" with the Linux eco-system, my suggestion is:

#1 Prove that you want to contribute to the Linux kernel and get your veeamsnap code mainlined.
The license is already compatible, your veeamsnap code just needs to be reviewed and improved through the review process.
This will result in an even better product.

#2 Propose your adjustments to the Linux kernel, that you need to enable the functionality that's wanted.
Point out, that you have (or are actively in progress of) mainlining your module.
Put forth a patch or set of patches that implements the feature(s) you want the kernel to have.

#3 Linux in general is very willing to "play-ball" IF YOU ARE. That manifests itself with YOU contributing alongside everyone else.
Whining about the lack of "corporate infrastructure" to push around in the newsletter is a complete non-starter. By doing so, you are telling everyone, that you don't give a **** and just want to benefit of everyone else's work.

#4 Jens Axboe explained the requirements very well in his reply to your patch proposal: https://lkml.org/lkml/2020/8/28/515
The relevant part of the reply is: "If there's a strong use case *in* the kernel, then such functionality could be entertained." I would argue that you have a really good case for getting VAL to work again, but the case is null-and-void until you fix #1, so please get to work :)

The alternative is that Veeam can convince the other 21000'ish contributors to change their agreed upon ways https://www.phoronix.com/scan.php?page= ... ts-EOY2019
I would argue that it's much easier to pick up the ball and start playing.

Gostev
SVP, Product Management
Posts: 26706
Liked: 4277 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Veeam for linux 5.8

Post by Gostev »

Ejdesgaard wrote: Aug 31, 2020 9:35 pmFirst things first, this should not be taken as me trying to be rude
But you absolutely are being rude?

Funny you should say this right before mentioning me three (!) times in a derogatory way in the single post, all completely unjustified. First you said that I "managed to forget" relevant information (implying this was done on purpose). Then, you said I was "ranting about the way Linux works" after receiving the clear response from maintainers.

Yet, all of this totally unnecessary bashing was added on a single wrong assumption that I write a newsletter on the very same day you receive it. You did not even consider I could have written it a few days prior, to keep my weekend free. Or many other possibilities why a Friday response to the specific developer did not make it into a Sunday newsletter written by a different person. No, instead you immediately rushed to make nasty comments, going as low as saying that I " don't give a **** ".

Besides, this post was not just an exception from the rule. Remembering your other posts here, they are often along the same lines. It's like you're honestly trying to help and bring value, but at the same time purposely express your thoughts with most negative vibes practically possible. It's like you're feeding off this. Think about it, and if this is something you simply cannot control - then I guess it will be best for everyone if you just don't participate in this community at all. There are plenty of other to choose from, where such behavior is tolerated or even encouraged.

I will be locking this thread now, since this is not the kind of conversations we want all future readers to "enjoy" reading through.

Gostev
SVP, Product Management
Posts: 26706
Liked: 4277 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Veeam for linux 5.8

Post by Gostev » 1 person likes this post

@jandrewartha to answer your question: as you can see from the latest updates following the link you shared, we did start to work on the in-tree kernel modules, as the maintainer is very supportive to this course of action. This has always been our vision of the ultimate design anyway, and is the very reason why we decided to license these modules with GPLv2 back when we started working on v1.

Unfortunately, the bigger issue is that the same does mean a number of kernel versions will remain unsupported forever, as it may take a while before our kernel modules are accepted (if they are accepted). But for example, kernel version 5.9 is already in the RC stage.

However, just like I said in the latest newsletter, we will explore a possibility of distribution-specific patching for the impacted kernel versions directly with the corresponding vendors of leading distributions.

Also, I'm very sorry for having to lock your topic due to the rude response from another poster. We don't usually delete anything, so this is the only option to prevent further "shooting". Please, feel free to create another topic about this in the future. And needless to say, I will keep providing updates in the weekly newsletter as we go.

Locked

Who is online

Users browsing this forum: No registered users and 5 guests