[lustre-discuss] KMOD vs DKMS

Riccardo Veraldi Riccardo.Veraldi at cnaf.infn.it
Wed Jul 19 21:42:29 PDT 2017


dkms is much more convenient if you plan to stay up to date with kernel
patching.
You do not need to rebuild a new kmod rpm every time yum upate will
upgrade your kernel to latest patch level,
also I do not like that weak-updates kernel module solution (with
symbolic links).
I am using dkms building my own lustre rpm (with only ZFS support, not
ldiskfs) since 2.8.0 and I am quite satisfied.


On 7/18/17 10:41 AM, Rick Wagner wrote:
> Hi Brian,
>
> I consider build processes somewhat fragile, especially when you expect to get the same results across a large number of hosts, like a set of Lustre servers. As a result, I favor building a single set of RPMs, testing them, and then pushing an update to the production servers. So count me in the kmod camp.
>
> In the case of a small number of NFS servers, I might go with dkms for convenience.
>
> —Rick
>
>> On Jul 18, 2017, at 10:22 AM, Brian Andrus <toomuchit at gmail.com> wrote:
>>
>> All,
>>
>> I have been watching some of the discussions/issues folks have with building lustre and I am wondering what the consensus is on the two approaches.
>>
>> Myself, I have been building my own RPMs for some time and it seemed to me that the general direction of linux was to move toward kmod and away from dkms, so I redesigned my build scripts to use zfs/kmod and dropped ldiskfs. Certainly, this has made life easier when there are kernel updates :)
>>
>> So if there is a choice between the two, what is preferred and why?
>>
>> Hopefully this doesn't start a war or anything...
>>
>> Brian Andrus
>> Firstspot, Inc.
>>
>> _______________________________________________
>> lustre-discuss mailing list
>> lustre-discuss at lists.lustre.org
>> http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
> _______________________________________________
> lustre-discuss mailing list
> lustre-discuss at lists.lustre.org
> http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
>



More information about the lustre-discuss mailing list