| |||||||||||||
EVMS changes directionEVMS changes directionPosted Nov 7, 2002 19:06 UTC (Thu) by job (guest, #670)Parent article: EVMS changes direction 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?
(Log in to post comments)
EVMS changes direction Posted Nov 8, 2002 11:36 UTC (Fri) by Wol (guest, #4433) [Link] 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
|
|||||||||||||