Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
That's not quite what I meant. The "add-on" source can't really be the same as the "built-in" pre-compiled modules. One very important reason is that the "built-in" version comes with the modules "kmp-default" and "kmp-bigsmp" which the "add-on" source can't possibly provide. these are specialized versions of the kernel, which are not part of and cannot be part of the source or rpm add-on packages. There must be a performance difference or "lower-level" (raw) access difference between the two. for example: as a service, you can actually kill a service (kill -15 if you have to), but the kernel can't be killed (at least not without killing the whole system). the other part is the boot process, which is mentioned, but using boot.localis not as good (IMHO). I've seen some performance differences between them, but that could be due to crappy hardware ;) On 2/11/07, Armando Ortiz <armandoo at verizon.net> wrote: > > 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... ^_^ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20070212/1d975156/attachment.htm>