[DRBD-user] drbd source "add-on" vs "built-in" ?

Armando Ortiz armandoo at verizon.net
Sun Feb 11 23:39:54 CET 2007

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


Dan Gahlinger wrote:
> I have a question which perhaps many people might have,
>
> Is there any performance or reliability difference between using the
> "add-on" drbd source download
>
> or using the "built-in" kernel modules in Suse such as
> "kmp-bigsmp" and so forth?
>
Other than being, perhaps, architecture-specific, I honestly don't think 
you'd get much performance out of it.  Most of the performance issues 
are relative to the underlying hardware - harddrive read/write speed vs. 
network bandwidth.
> I noticed in Suse 10.2 they not only include the RPM of DRBD,
> but they also include two other packages which are NOT included if you
> just use the source. they are "kmp-default" and "kmp-bigsmp" (there is
> a third, but I don't use it, it is "kmp-xen").
>
I am also running OpenSuse 10.2 with DRBD as fileservers, but I 
installed the pre-compiled modules as opposed to doing the source 
myself.  It was much easier, and quicker, to set up.
> I was just wondering about reliability or stability differences 
> between them?
> I'm thinking the built-in would be preferable. Why? because it got me
> to thinking about booting.
>
> When the system boots, one of the first things it does is mount the
> filesystems (fstab),
> but the drbd volume is an EVMS which means it needs drbd running in
> order to mount it.
> But it seems to become a catch-22.
>
> You can't mount the volume without drbd running, and you cant run the
> drbd "service' (add-on) without mounting the filesystem. Which is
> where the kernel modules, and specialized kernels come in, they'd get
> loaded with the kernel.
>
You could try mounting these via boot.local instead of fstab so you can 
do any last-minute autoprepping before the system is up and running, 
which includes starting servers that might use the facilities after 
they've been made available.
> part two is - as a "built-in" it's part of the kernel, specially
> compiled, which means its a bit "lower level" than just a service.
>
> or am I completely off-track here?
I'm not quite sure what you mean by a 'lower level' than just a service 
- whether or not you compile a module outside of the distribution vs. 
using one provided for you as somewhat irrelevant, no???

This is the beauty of tracks - if you get off of one of them, you can 
easily jump on another... ^_^




More information about the drbd-user mailing list