Release 2 of the Pliant utility for reconfiguring (adding disks, changing the RAID level or the chunk size) a software RAID without loosing (at your own risks: test it on sample datas before using it on real ones) datas is available. The new code is expected to event survive to a disk failure in the middle of the RAID reconfiguration (provided the RAID level is 1 or 5 :-) ) The script will be included in Pliant release 28 that will be available at http://pliant.cams.ehess.fr/ in a few days. If some of you want to stress test it, I can now send a snapshot by email because the changes that will append in Pliant before release 28 have nothing to do with this RAID script. ----- Ingo wrote that this script should be written in C for several reasons: - speed - portability These are my answers to these arguments: - Although it would be faster if written in C because Pliant code generator is not as efficient as GCC, this is not that important because: . there is nothing in Pliant itself that make it slower than C, so at some point, the speed will be excacly the same as with C. . on a 300Mhz processor, the conversion speed could be about 10 MB/s, so it's completely IO bounded on my laptop. - Now the portability argument is very valuable because Pliant currently runs only and i386 (Alpha port planned next year, but others are not scheduled yet). - There is an additional strong argument for writting the script in C: Pliant is a young language that changes much for the moment. Now, these are my arguments for writting the script in Pliant: - Compiling a C program is a big problem because a C compiler is idiot: you need a set of extra tools (make, .configure script, ...) in order to cope with differences on various machines. On the other hand, a Pliant script is always run directly from it's source code (Pliant is what I call a dynamic compiler, you could also read on the fly, or not stupid), so for free softwares it's definetly better because you get rid of the binaries nightmare. - In standard C, there is no provision for 64 bits arithmetics, whereas in Pliant, the unlimited intergers are a basic feature. - A Pliant program is faster debugged because when you set the debugging level to 2 or more, all arithmetic overflows are reported: it was important for such an application. - The Pliant code is probably shorter than the C code would be. - I prefer Pliant (I designed it :-) ) Ingo also specifyed that at some point, this conversion should be done on the fly in kernel space. This would be the ultimate rafinement, but it does not worth the troubles (except for changing the chunk size) until we get the ability to resize an ext2 partition without umounting it. I seems to be already possible, but with strong restrictions, so, for the moment, the 'ext2resize' utility seems to be the safest solution. Now believing that no Pliant code will go in Linux kernel might also be wrong on the long term. My opinion is that it may well append the other way round at some point. Pliant would be the boot loader that would load and compile on the fly the Linux kernel. In Pliant, there is provision for several syntaxes, so the parts of Linux that are written in C would be seen as Pliant programs: a Pliant C parser module will make it transparent. Now Pliant would bring the flexibility to Linux kernel: the ability to compile on the fly some drivers when the harward is detected or some network frames are received, or recompile on the fly with different optimising options, when some statistics have been collected, and the cost would only be a bigger kernel (because Pliant contains the compiler and some extra informations). Lastly Pliant compiling machinery is much more powerfull than C compilers one, so on a large project such as the Linux kernel you can get a much cleaner and easyer to maintain code, even if keeping the C syntax. ----- As a conclusion, I will maintain the script, in Pliant, until somebody rewrites it in C. Ingo, please don't include the script in the RAID user levels tools since it may need to be adjusted if I make more changes in Pliant itself: just specifying that it's available and the Pliant URL. I may also send you a small HTML page specifying how to use it, which could be included in the documentation of the user level tools. This is a sample usage of the script: pliant module /pliant/admin/raid.pli command 'raid_convert "/dev/md0" "/dev/hda5 /dev/hda6 /dev/hda7" "/dev/hda5 /dev/hda6 /dev/hda7 /dev/hda8" 5 64*2^10' The third parameter (5) is the requested RAID level. The fourth parameter (64*2^10=64K) is the requested chunk size. Regards, Hubert Tonneau
