Slashdot Mirror
DRBD To Be Included In Linux Kernel 2.6.33
An anonymous reader writes "The long-time Linux kernel module for block replication over TCP, DRBD, has been accepted as part of the main Linux kernel. Amid much fanfare and some slight controversy, Linus has pulled the DRBD source into the 2.6.33 tree, expected to release February, 2010. DRBD has existed as open source and been available in major distros for 10 years, but lived outside the main kernel tree in the hands of LINBIT, based in Vienna. Being accepted into the main kernel tree means better cooperation and wider user accessibility to HA data replication."
About 15 years ago, I worked for a place that used Tru64. It offered very similar technology to this. Frankly, we found typical hardware solutions to work better. Software is better at some things, but for work like this, you want it done as much in hardware as is possible.
The "DR" stands for Distributed and Replicated. DRBD is way higher-level in function, but integrated lower-level than the simple userspace daemon that the server side of NBD uses.
Read the docs, the differences should be blindingly obvious.
We use DRBD for some very mission critical servers that require total redundancy. Combined with Heartbeat I can fail over from one server to another without any single point of failure. We've been using it for more then 5 years, and never had any major issues with it. It will be great to have it in the mainline kernel.
Why is it so hot? Where am I going? What am I doing in this handbasket?
It's a kernel module. Don't like it, don't load it.
Your "requirement": "something that the majority of Linux users need, or want" is irrelevant. There are LOTS and LOTS of drivers in the kernel for which this is true, probably MOST of them.
"it's just another layer of complexity" - NOT if you don't install the userland packages or load the kernel module.
"Personally" - you got a lotta nerve representing yourself as having a valid opinion about what does and does not constitute a useful feature.
A closed mouth gathers no foot.
You want "make localmodconfig", which I think was also added recently, possibly to 2.6.32 actually. This builds a kernel using a local .config file, except that it only compiles modules that show up in lsmod. So if you boot off your vendor kernel with a squillion modules, let it load the modules you actually *use* then do make localmodconfig, you can make a kernel that only contains those modules. I don't know what it does if module names etc change, maybe you'd need manual fixup then - should still be less work than you currently are doing though.
There's some explanation here, though it might be for an out-of-date version of the patch:
http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-09/msg04230.html
As the other reply said, make oldconfig is also useful to important settings from a previously configured kernel, can save a lot of time.
Another way of putting (some configurations of) DRBD is probably "Networked block device RAID, but more flexible".
You should consider a career as a teacher.
And then you should shoot yourself in your fucking brainpan.
Just wait 'til next week when the Gentoo folks finish compiling and finally see this story.
People who build (and test) their own custom kernels are important. Sometimes, a bug won't show up except with some weird combination of kernel options, because some code path dependencies are missed with the fully configured kernels that the distros build for you.
I admin AIX systems for my day job... One thing that's really nice about AIX is that the filesystem and underlying block device is highly integrated. This means that to resize a volume you can run a single command that does it on the fly. For AIX admins who are new to Linux it seems a step backwards and they liken it to HP-UX or some earlier volume management...
Ahh, but the beauty of having separate filesystem and block device is that it's so damn flexible. I can build an LVM volume group on iSCSI LUNs exported from a another system. In that VG I can create a set of LUNs that I can use for the basis of my DRBD volume. In that DRBD volume I can carve out other disks. Or I can multipath them. Or create a software RAID.
Anyhoo, DRBD is a really cool technology. It gives the ability to create HA pairs on the cheap. You can put anything from a shared apache docroot there to the disks for Oracle RAC. With fast networking available for cheap, almost any shop can have the toys that were once only affordable to big companies...
I dont like drbd (though i've used it for a while)... its a massive convoluted and complex mess and fairly inflexible.
Personally, im hoping dm-replicator gets near completion sometime soon though details of it are rather scarce (i do have a kernel built with the dm-replicator patches, but trying to do anything with it seems near impossible)...
I do a fair amount of work inside the storage world and drbd is just such a mess in so many ways.
I sounds very critical and so forth to drbd and thats not the way i mean to come across. What I really am trying to say is that its bloated for the small amount of functionality it does and with a couple of minor tweeks could do much MUCH more. Its a kewl piece of software, but like many FOSS projects has a hideous, weighty config prone to confusion (something you just dont need with DR).
Still, that is the way it is!
They are called modules for a reason: You can add or remove at will, including whether or not you bother to build them at all. To say modules are "built into the kernel" is incorrect; module code is included with the kernel source code, but the modules themselves are only built and used if you choose.
As concerns the "insanity" of configuring a kernel, here again you have a choice: Use Ubuntu. But if you want a fast, lean, mean machine you really do want to craft your kernel to fit your specific needs.
Everything in the Universe sucks: It's the law!
i'm sorry to say, but that's not a good attitude. and i'm being polite here.
developers need testers. some arrogant assholes might claim they don't, but then they're known as ones. now, to attract testers you not only are polite to them, you also do not discourage them by breaking or ignoring things that hamper them (but might not concern casual users), you actually should build tools and other support functionality for testing.
essentially, having less testers will impact quality of the software for everybody else, so casual users also should desire for the project to have more testers.
i'm glad that at least some kernel hackers recognise this, and 2.6.32 actually has support for new configuration method, which looks at already loaded modules and some other stuff to create trimmed down kernel config - http://kernelnewbies.org/LinuxChanges#head-11f54cdac41ad6150ef817fd68597554d9d05a5f
Rich
I've been using linux as my main OS for the past 6 to 7 years and in all this time I never experienced any linux lockup., not even back in the beginning where we couldn't do away with compiling software by hand (where the "you need to know how to program to use linux!" was born) and when the only way to make my DSL modem work was to run a weird, convoluted shell script through the command line. So, that "lockup" accusation is, at least, very odd, particularly in this day and age.
Moreover, that weird accusation of "file permissions errors" and the need to have IT staff hired with the sole purpose of "fixing drivers" and "edit config files" also sounds like bullshit to me, specially in today's world and even after the GP stated that their workstations worked with XP and win2k, a pair of OSes which are more problematic, less stable and with a less extensive hardware support than today's popular linux distributions.
And of course, let's not forget that the GP made a point in launching that long-winded anti-linux troll while intentionally keeping out fundamental details such as what linux distribution was supposed to be installed, not to mention that it was posted anonymously. To put it in other words, the GP wrote that post intending to attack the entire linux world, insinuating that that sort of problem affects each and all distros and not a specific one, and it did it so intending to be a troll.
So, it would only be seen as "-1 truth hurts" if you didn't read the post and you also considered a "your mother is a whore" type of post as "-1 truth hurts". It's not, it is meant to insult and it is perfectly void of any objective statement.
Slashdot, fix your code or at least hire someone who is competent at it to do it for you.
It isn't. In our mid/large company, we have hundreds of Linux workstations, and they've all been working for years without a single hitch, from day one. No permission problems, never had an update causing significant issues, don't even ALLOW users to get a command-line, etc. Vastly easier to debug when there is a problem, and has allowed the company to replace a large group of Windows experts with a small group of Linux experts, and the vastly improved productivity has allowed the company to significantly reduce the number of employees (or rather, just cease to replace them when there is turnover).
Just the other day I noticed the uptime on one of the Linux workstations was over a year at this point. No lockups. The few issues we've had with the systems have been directly traced to hardware problems.
If yours is a true story (which I seriously doubt) you should look at hiring at least one half-way decent Linux SysAdmin at a reasonable salary to fix the pathological issues with the installation which was likely done by minimum-wage idiots without a clue.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Ah, Linux gets disk level clustering?
It is interesting to compare with what VMS offered 25 years ago:
- VMS could have multiple nodes (can DRBD? It is not obvious from the web site.)
- All VMS nodes have read and write access to the file systems
- The distributed lock manager helps with file locking in this case.
- VMS has the concept of quorum to avoid the "split brain" syndrom mentioned on the web page.
)9TSS