LWN: Comments on "EVMS changes direction"

EVMS changes direction

Wol — 2002-11-08T11:36:49+00:00

This would require all kernels to be linked with an initramfs image, which doesn't really improve anything. Is the kernel really going this way, and why?

AFAICT, yes

It makes for a far smaller kernel, as loading modules requires loads of user-space or call-once code, and this means all this crud can be run in user space, and then dropped. With current kernels, I don't know what the figure is, but it wouldn't surprise me if 50% of the RAM occupied by the kernel is "dead space", and the kernel guys want to get rid of it.

This discovery etc code is a classic example - it only runs on boot, so why should it be in the kernel, cluttering up RAM for evermore?

Cheers,
Wol

EVMS changes direction

job — 2002-11-07T19:06:27+00:00

But .. but ... EVMS offers more functionality than the in-kernel DM och MD do! (And these two overlap, because DM can stripe volumes as well -- so the rest of MD functionality really should be moved to DM as well.) The article mentions bad block reallocation but there's more in there. I don't think it's possible to implement this on DM. What about it?

Also, the in-kernel discovery is *very* nice to have (being a sysadmin) and it really simplifies booting. I guess the initramfs is good enough but then I want the partition discovery and such overly simple tools for logical volumes to be moved to userspace as well! This would require all kernels to be linked with an initramfs image, which doesn't really improve anything. Is the kernel really going this way, and why?

EVMS changes direction

Peter — 2002-11-06T22:04:58+00:00

Very impressive. Kudos to the development team. Looks like the whole system will improve as a result.

Seconded. I've been hoping for the past month or two that they would make this decision - architecturally, DM and MD are good solutions and are flexible enough to support layering other stuff on top of them, including both LVM2 and EVMS.

Classy move, EVMS people.

EVMS changes direction

Peter — 2002-11-06T22:01:27+00:00

This means if we use evms on a 2.4 system, we can't experiment with a 2.5 kernel. Unfortunate.

Welcome to my world. (: I use LVM, so until DM was included in the 2.5 kernel I couldn't test it - LVM did not survive the block device changes in 2.5.1 and 2.5.2, so it has been broken for basically the whole series.

Besides, if you read the message carefully, you'll note that Kevin is hoping to complete the changeover in early 2003 and will continue to maintain the current kernel patch until then.

At that point, in order to boot both 2.4 and 2.5 kernels you will have to figure out how to make two versions of the userspace tools coexist and select themselves when the appropriate kernel boots. Again - welcome to my world. LVM was like this for quite awhile in the 2.2 and 2.3 days - I used four different versions of its rapidly evolving ABI, with four sets of userspace tools, during that time. I hacked up the LVM tools to do this detection / selection, and a very similar approach was eventually implemented in the Debian packaging. It's annoying but doable. Quite possibly the EVMS maintainers will actually do that part for you; if not, perhaps someone like Debian will.

Oh, I forgot: they said they'll also be supporting DM on 2.4 kernels, so when the fateful flag day comes, you could just recompile your 2.4 kernel with the device mapper patch.

EVMS changes direction

hisdad — 2002-11-06T18:48:22+00:00

This means if we use evms on a 2.4 system, we can't experiment with a 2.5 kernel.
Unfortunate.

EVMS changes direction

dkite — 2002-11-06T15:21:25+00:00

This should be added to the kernel howto's. "What to do if your project you have been working on for years is not included", or "Reasons not to fork".

Very impressive. Kudos to the development team. Looks like the whole system will improve as a result.

Derek