From: James M. <Jam...@ho...> - 2003-10-28 09:44:41
|
I saw a comment about updateing loopback to do the COW file functions, some of Jeff Dike's new COW stuff seems to indicate that he was looking at something like that though the last status I remember was don't use it yet :/ some of it seems to have been removed from more recent UMLs If you want to hack on it I would suggest looking at the device mapper as I seem to remember comments about the loop device being a poor example to follow, and not being maintained well, and the new device mapper already has examples of feeding requests back into the block queue, using DM you could split the request for COW data and backing data to seperate ubd devices, note that it would be nice to have more ubd devices when doing this... Even better, if you hack it well it would also work on host kernels, well 2.6+ host kernels but DM appears to be the wave of the future, and COW files on real devices would be sweet. ******** Regarding the new COW V3 format Jeff I saw your comments about 1) Alignment field in header - to align bitmap & data 2) mmapping option - to mmap the data and bitmap 3) cow format option - to provide for alternate layouts 4) moved backing file to end of header - this puts all the fixed length stuff first 5) fixed rounding bug - not sure which rounding but this was 6) updated header to fixed lengths - well mostly the time was still a local fomat 7) d option - to prevent treating a COW file as a COW file (a later option I think) ******** Commentary on features 1) Alignment -- the previous problems with alignment were due to reading a header that was not a exact multiple of sector size this is why it would not work on raw devices, it dumped out trying to read the header not the data, since it checks first if it is a cow header and quits on a read error it could not even be the backing file the alignment of the bitmap and data sectors was not a problem but fixing that would be nice to have, also I think that putting the real offsets rather then a alignment value would make more sense if it is aligned wrong it can't be easily changed. 2) mmaping option -- my problem has always been the reverse my UMLs ran out of address space even when just mmapping the COW bitmap, I can picture paging in sections of the data by mmap, but as proposed I would expect to run out of address space on my first ubd of ~2-4GiB since I have tried (using my previous patch set) a 64TiB array (sparse) I would expect to use all of memory for the mmap in short order. I am not sure that mmapping is faster than pread/pwrite which I was using earlier, I expect that both would be faster than the seek and then read+write that currently is in use. 3) cow format option - the ISAM files that have been proposed as alternatives to the sparse COW files that V2 uses for DOS format filesystems which don't do spare files well, I seem to remember ~3 different formats for different puropses some of which would require different layous for the header ... ick, and I have thought it would be easier to just use new V4..6 for example as the COW version instead besides I don't seem to remember anyone showing code, I just made a few fragments as tests. 4) moving backing file to end of structure -- I think I may have suggested this it makes it much easier for me at least to read the hex dumps on the COW file, also zeroing the backing file array make it easier to read, I seemed to get mostly 'Z' in my dumps which is ok but \0 is nicer, I have slab posioning turned on. 5) fixed rounding bug - I am not sure which of the rounding bugs this refers to, I think it is the calculate cowbit map size but there was also the one about passing 2 words of the bitmap between ubd_kern and ubd_user which would walk off the end of the mmap I was working on haveing the bitmap only read from the user side since I think it makes the ubd_kern driver much clearer 6) update header to fixed lengths - another portability bit I may have suggested, I think that the time should be converted also. 7) d option - this is another approach that should work when using raw devices in addation to its commented purpose of letting UML read a COW file as a plain file. ******** Other featues I seem to remember coding examples for A) having C/H/S in the header - I would like to be able to have other partition layouts so that real disk images can be used. B) treating the COW stuff as private_data to the ubd_kern.c so that it can stack, and with this we can push the COW option parsing over to _user side and then the _user side can also be used as libaray for uml_moo, one implementation is of course safer in that fixes don't need to match in two codebases. C) removing the limitations on 8 ubd devices this gets rather messy if the COW info (fds, bitmap, is not private to the _user side D) create COW file by seek rather then writing lots of zeros E) I have a preference for making the COW layer look like other linux file functions i.e. open,close,[p]read,[p]write. I prefer the pread/pwrite since in halves the number of system calls by not needing a seek for every read/write F) paged COW bitmap - I run out of memory when I do strange things like wanting a COW file on >512GiB files so I did a paged bitmap G) alignment - the header needs to be padded one of the reason was that my test versions had both length and offsets for the backing file name, COW bitmap, and data area if this is done they can be placed in any order and extra fields can be added to the header without breaking the exisiting code, the other option is to use something like the tagged headers of e.g. zip files, well one of those DOS tar replacements. H) Alignment 2 - another reason for offsets is that when problems are discoved like the offset calculation the code to read the old format must still be present in its errornous form to allow for reading the previous COW files otherwise the corrected calculation will index to the wrong part of the file producing a off by 1 error on the sector address of each data sector and having all the COW sector adresses off by 1 will be very corrupt as some sectors, those in the COW file will have that off by 1 and those in the backing file won't ... ick .... I) the fast bitmap operations - the bitmap test/set/clear functions can be done with shift (<<,>>) and &,| this code is both faster and smaller then the current *,/,% code ******** Stuff that I have not done but would be willing to code I) paged COW mmap - if you really think that mmap is much more efficient than pread I will try out a paged version so I don't run out of memory II) paged data mmap - and I am willing to do the same for the data if you think it would help alot III) one of the ISAM files as a example if someone would be willing to use it for a while. One simple example is ok but there has not been alot of call for ISAM on the list, and I hate writing brand new dead code.... IV) updated moo program to convert several layers of COW file into one e.g. COWA,COWB,COWC,backing to produce COWA,backing2 also to update C/H/S for a new partition layout also change alignment of COW file for different requirements I like offsets rather than a single alignment value so that the file elements can be put in any order and have gaps of desired sizes. V) add in a sector size option so that we can play like CDROMs and that funny sectored hardware, Zip disk maybe? ******** Jeff you had said that you would like it in small parts I would offer converting to COW_open,close,read,write first with the private_data so ubd_kern gets cleaned up. then converting to dynamic disk allocation, stackable COW files get quite easy with private_data it can just recurse using the private_data to find the next layer, and since it does not require static information from ubd_kern it can stack, my notes indicate I was running 25 deep COW file stacks. Or perhaps the conversion to external COW version files, cow_v1.[ch] etc.which makes plugging in new versions easier e.g. V3 & ISAM, I seem to recall testing with the fops proposal, and one where a index was used to select which read/write routines were used, fops was more the linux kernal style though. Paged mmap for the bitmap and data could occur in any order with the other work The faster bitops are a tranparent replacement. This is somewhat backwards in that it stacks the COW file under the ubd device, but this is pretty much how it has always been done and once the ubd_kern side is cleaned up putting a equivalent on top via DM should not make things too complex, I seem to remember booting from DM or worse yet loopback is a pain. Then later once DM is working nicely we can drop the COW layer under ubd easily by just replacing the COW_open/close/read/write with the normal open/close/read/write functions and let DM do all the hard work, alas not in the 2.4 roadmap, though it does seem like something that may get backported... Sorry to be so long but I haven't done much on UML but some work on booting of the ThinkNIC distribution on UML, and way to much fighting with windows at work. James McMechan |
From: Jeff D. <jd...@ad...> - 2003-10-28 17:17:34
|
Jam...@ho... said: > 1) Alignment -- the previous problems with alignment were due to > reading a header that was not a exact multiple of sector size this is > why it would not work on raw devices, it dumped out trying to read the > header not the data, since it checks first if it is a cow header and > quits on a read error it could not even be the backing file the > alignment of the bitmap and data sectors was not a problem but fixing > that would be nice to have, also I think that putting the real offsets > rather then a alignment value would make more sense if it is aligned > wrong it can't be easily changed. The alignment was really needed for mmap. The data needed to be page aligned in order to be mmapped. I aligned everything else more or less for the hell of it. It does have the advantage that there is now some extra room after the header that can be used for new stuff without necessarily needing a new version of the format. > 2) mmaping option -- my problem has always been the reverse my UMLs > ran out of address space even when just mmapping the COW bitmap, I can > picture paging in sections of the data by mmap, but as proposed I > would expect to run out of address space on my first ubd of ~2-4GiB > since I have tried (using my previous patch set) a 64TiB array > (sparse) I would expect to use all of memory for the mmap in short > order. I am not sure that mmapping is faster than pread/pwrite which I > was using earlier, I expect that both would be faster than the seek > and then read+write that currently is in use. First, the mmap option is used to map pages from the device directly into UML physical memory. So, address space isn't a problem here because it's already allocated. Second, 64 bit machines have lots of address space. As for speed, using mmap trades a tlb flush for data copying. Here, a kernel build is about the same speed either way. It would be a win for very write-dominated loads, though. The real reason for doing it was to save memory on the host. pread/pwrite would be good. I'm not too interested in reducing the system call count, but it has other advantages. It eliminates a bit of code. It also makes the seek and read/write atomic, which isn't an issue now, but it may become one in the future. > 3) cow format option - the ISAM files that have been proposed as > alternatives to the sparse COW files that V2 uses for DOS format > filesystems which don't do spare files well, I seem to remember ~3 > different formats for different puropses some of which would require > different layous for the header ... ick, and I have thought it would > be easier to just use new V4..6 for example as the COW version instead > besides I don't seem to remember anyone showing code, I just made a > few fragments as tests. It would be good to have at least one working alternative so we can see what changes are needed. Then we can split the header between stuff that all formats will need and stuff that's format zero-specific. That should make it easier to add new formats. Also, a non-sparse format will make it easier to put COW files on physical devices, where you want to use the space efficiently. > 5) fixed rounding bug - I am not sure which of the rounding bugs this > refers to, I think it is the calculate cowbit map size It is. > but there was > also the one about passing 2 words of the bitmap between ubd_kern and > ubd_user which would walk off the end of the mmap I was working on > haveing the bitmap only read from the user side since I think it makes > the ubd_kern driver much clearer Ummm, I don't remember that one. The problem is that the first word would be the last one in the bitmap, and the second word would be the one following that? > 6) update header to fixed lengths - another portability bit I may have > suggested, I think that the time should be converted also. I switched some of the fields - others I wasn't sure about so I left them alone. > A) having C/H/S in the header - I would like to be able to have other > partition layouts so that real disk images can be used. I don't like this in the COW header. If you want CHS, you want it for all devices, COWed or not. So some way of specifying geometry is needed that doesn't involve the COW header. > B) treating the COW stuff as private_data to the ubd_kern.c so that it > can stack, and with this we can push the COW option parsing over to > _user side and then the _user side can also be used as libaray for > uml_moo, one implementation is of course safer in that fixes don't > need to match in two codebases. The COW stuff needs to be removed from the ubd driver totally, and turned into a separate driver. This is why I didn't merge your COW layering stuff. The real way to do that is cow0=cow0_file,/dev/cow1 cow1=cow1_file,backing_file > D) create COW file by seek rather then writing lots of zeros This is done, and has been for a while. > F) paged COW bitmap - I run out of memory when I do strange things > like wanting a COW file on >512GiB files so I did a paged bitmap Yeah. Don't know what to do about this. One wacko idea I was pondering was (in skas mode), making multiple kernel address spaces which are the same, except they have different sections of the COW bitmap mapped. So, rather than mapping the bitmap in and out, you switch to the address space that has the section you need. > G) alignment - the header needs to be padded one of the reason was > that my test versions had both length and offsets for the backing file > name, COW bitmap, and data area if this is done they can be placed in > any order and extra fields can be added to the header without breaking > the exisiting code, the other option is to use something like the > tagged headers of e.g. zip files, well one of those DOS tar > replacements. This sounds over-engineered to me. I'd rather leave things more constrained as they are now, and make people have to justify new things that don't fit. > I would offer converting to COW_open,close,read,write first with the > private_data so ubd_kern gets cleaned up. then converting to dynamic > disk allocation, stackable COW files get quite easy with private_data > it can just recurse using the private_data to find the next layer, and > since it does not require static information from ubd_kern it can > stack, my notes indicate I was running 25 deep COW file stacks. I'd like the separate COW driver. The ubd driver is messy enough as it is, and I'd just like the COW stuff out of there. > Or perhaps the conversion to external COW version files, cow_v1.[ch] > etc.which makes plugging in new versions easier e.g. V3 & ISAM, I seem > to recall testing with the fops proposal, and one where a index was > used to select which read/write routines were used, fops was more the > linux kernal style though. A working non-sparse COW file format would be useful. > Paged mmap for the bitmap and data could occur in any order with the > other work That would be interesting. I think that qualifies as research and experimentation at this point. > The faster bitops are a tranparent replacement. Yeah, although I don't think it makes much difference overall. Jeff |
From: James M. <Jam...@ho...> - 2003-10-29 16:22:49
|
> Jam...@ho... said: > > 1) Alignment -- the previous problems with alignment were due to > > The alignment was really needed for mmap. The data needed to be page aligned > in order to be mmapped. I aligned everything else more or less for the > hell of it. It does have the advantage that there is now some extra room > after the header that can be used for new stuff without necessarily needing > a new version of the format. Yes, but I will argue that having the offsets directly in the header rather than the __u32 alignment; would seem to make more sense, the offsets are what are needed to compute where in the file to read/mmap, the pad size can actually be different, and the prefered natural size for read/mmap can also be different and we might want to set both at runtime a pad of 512 for raw devices and 64K for natural size since the read/mmap would likely gain > > > 2) mmaping option -- my problem has always been the reverse my UMLs > > First, the mmap option is used to map pages from the device directly into > UML physical memory. So, address space isn't a problem here because it's > already allocated. I may be missunderstanding this works, it mmaps in from the device and then copies to/from the uml buffer, rather than reading/writing from the uml buffer? I think we can't mmap the pages from the device to the buffer address? The read might have the wrong model since any writes to the just read buffer would be via mmap be copied back to the device. MAP_PRIVATE notes that it is unspecified if writes to the mmaped area will appear in the mmaped area, and might end up with SEGV on NORESERVE Write would have the same soft of problem in that the mmap should occur before the data is copied into the buffer not when the ubd driver is called > > Second, 64 bit machines have lots of address space. > Yes that will be nice but I expect that even 5 years from now 32bit systems will still be quite common, and I don't have a 64bit system yet :( > As for speed, using mmap trades a tlb flush for data copying. Here, a kernel > build is about the same speed either way. It would be a win for very > write-dominated loads, though. The real reason for doing it was to save > memory on the host. Save memory on host seems like a good reason., I don't see where write gains though > pread/pwrite would be good. I'm not too interested in reducing the system call > count, but it has other advantages. It eliminates a bit of code. It also > makes the seek and read/write atomic, which isn't an issue now, but it may > become one in the future. I also like the look since it does exactly what we want. > > 3) cow format option - the ISAM files that have been proposed as > > It would be good to have at least one working alternative so we can see what > changes are needed. Then we can split the header between stuff that all > formats will need and stuff that's format zero-specific. That should make > it easier to add new formats. Also, a non-sparse format will make it easier > to put COW files on physical devices, where you want to use the space > efficiently. I am willing put in one of the stupid ones, I think you could gain on physical devices only if you were running something like LVM which allows resizing or were using a device that was smaller than the backing device + map which will fail a write it you keep using it, that of course is very bad. > > 5) fixed rounding bug - I am not sure which of the rounding bugs this > > refers to, I think it is the calculate cowbit map size > > It is. > > > but there was > > also the one about passing 2 words of the bitmap between ubd_kern and > > ubd_user which would walk off the end of the mmap I was working on > > haveing the bitmap only read from the user side since I think it makes > > the ubd_kern driver much clearer > > Ummm, I don't remember that one. The problem is that the first word would > be the last one in the bitmap, and the second word would be the one following > that? Yes that one, I would have to recheck what I thought was wrong, and I could also be wrong myself :) > > 6) update header to fixed lengths - another portability bit I may have > > suggested, I think that the time should be converted also. > > I switched some of the fields - others I wasn't sure about so I left them > alone. Yes, I did regard it as progress but thought that time should be changed too. > > A) having C/H/S in the header - I would like to be able to have other > > partition layouts so that real disk images can be used. > > I don't like this in the COW header. If you want CHS, you want it for all > devices, COWed or not. So some way of specifying geometry is needed that > doesn't involve the COW header. Actually it just seemed logical to put it in there and for those that don't need COW use a degenerate header e.g. no bitmap/no data area/backing file is written to, or no bitmap/no backing file/data area is the disk image > > B) treating the COW stuff as private_data to the ubd_kern.c so that it > > can stack, and with this we can push the COW option parsing over to > > _user side and then the _user side can also be used as libaray for > > uml_moo, one implementation is of course safer in that fixes don't > > need to match in two codebases. > > The COW stuff needs to be removed from the ubd driver totally, and turned into > a separate driver. This is why I didn't merge your COW layering stuff. The > real way to do that is > cow0=cow0_file,/dev/cow1 cow1=cow1_file,backing_file I would think it would be easier to remove it, if it was not so tightly bound also are you sure you want to remove it, the layer above ubd should be DM based and would be the user inside of the UML setting up COW What we have now is a system feature under ubd that does not require that the user inside set it up, and is instead setup by the user outside of the UML at runtime. <lead balloon> If you want to get rid of the COW feature under the ubd. We could just delete it and use the DM functional equivialent from inside the UML. </lead balloon> > > D) create COW file by seek rather then writing lots of zeros > > This is done, and has been for a while. Sorry, I was checking my old info and was not sure it had made it in > > F) paged COW bitmap - I run out of memory when I do strange things > > like wanting a COW file on >512GiB files so I did a paged bitmap > > Yeah. Don't know what to do about this. One wacko idea I was pondering was > (in skas mode), making multiple kernel address spaces which are the same, except > they have different sections of the COW bitmap mapped. So, rather than mapping > the bitmap in and out, you switch to the address space that has the section > you need. Not so wacko, I had the same idea but what a pain and tt would still need another way. I was not mmapping I emulated it with a dirty flag and pread/pwrite since I was not sure about mmaping into the UML address space without mangleing your address spaces, I think I could have MAP_FIXED but pread/pwrite was safe > > G) alignment - the header needs to be padded one of the reason was > > that my test versions had both length and offsets for the backing file > > name, COW bitmap, and data area if this is done they can be placed in > > any order and extra fields can be added to the header without breaking > > the exisiting code, the other option is to use something like the > > tagged headers of e.g. zip files, well one of those DOS tar > > replacements. > > This sounds over-engineered to me. I'd rather leave things more constrained > as they are now, and make people have to justify new things that don't fit. Yes tagged headers seemed that way to me also. The length offset pairs I was using make the degenerate cases easier > > I would offer converting to COW_open,close,read,write first with the > > private_data so ubd_kern gets cleaned up. then converting to dynamic > > disk allocation, stackable COW files get quite easy with private_data > > it can just recurse using the private_data to find the next layer, and > > since it does not require static information from ubd_kern it can > > stack, my notes indicate I was running 25 deep COW file stacks. > > I'd like the separate COW driver. The ubd driver is messy enough as it is, > and I'd just like the COW stuff out of there. Well above ubd we can use DM from inside the UML but outside of the UML I still want to be able to set up COW files at the system level. Matt Zimmerman said that DM is in 2.4 which I had somehow missed and that the DM snapshot feature could be used in place of COW > > Or perhaps the conversion to external COW version files, cow_v1.[ch] > > etc.which makes plugging in new versions easier e.g. V3 & ISAM, I seem > > to recall testing with the fops proposal, and one where a index was > > used to select which read/write routines were used, fops was more the > > linux kernal style though. > > A working non-sparse COW file format would be useful. I am willing to do a stupid one. > > Paged mmap for the bitmap and data could occur in any order with the > > other work > > That would be interesting. I think that qualifies as research and > experimentation at this point. It was interesting, the bookkeeping was a hassle but not too hard Testing it was a bit of work though > > The faster bitops are a tranparent replacement. > > Yeah, although I don't think it makes much difference overall. Well not a huge amount, but I am an old programmer and still like my utilites in the classic forms. Especially stuff on the common/fast paths |
From: Matt Z. <md...@de...> - 2003-10-29 16:37:03
|
On Wed, Oct 29, 2003 at 06:16:18AM -0800, James McMechan wrote: > Well above ubd we can use DM from inside the UML but outside of the UML > I still want to be able to set up COW files at the system level. > Matt Zimmerman said that DM is in 2.4 which I had somehow missed and > that > the DM snapshot feature could be used in place of COW No, I said it was available...it is not in 2.4 stock, but a 2.4 patch is actively maintained; I use it on many systems. It might not be infeasible for it to be included in a later 2.4, but I don't track that sort of thing. -- - mdz |
From: Steve S. <sn...@fr...> - 2003-10-29 17:13:16
|
On Wed, Oct 29, 2003 at 06:16:18AM -0800, James McMechan wrote: > [Plenty interesting stuff about the future of COW] I did a kernel module to support user space loop devices. [ actually any userspace block device ] The idea is that you open a /dev/ulb[a-z] and the kernel module connects it to /dev/ulc[0-26] (major/minor are assigned automatically by the kernel) Then a user-space helper reads /dev/ulc0 for commands & data, and reads/writes somewhere (usually in a file), and then writes back the result to /dev/ulc0. For now it's heavily 2.4.x oriented... The code isn't in a really good shape (lots of hardcoded values) But, since i don't have much spare time i decided to publish it here in case of someone wants to have a look at it. The code should be almost self-explaining. I should be able to resume working on it soon, but anyway... your feedback is very welcome. ( i'm not a good C hacker, and i *do* like to improve myself ) URL: http://snide.free.fr/uldd/ Steve -- GPG public key available from http://snide.free.fr/gpg/snide.free.fr.asc Or by email to "snide at free.fr" with "send key pub" as subject Fingerprint: 19D7 12ED 5A37 4F29 8FDA 19B0 6DFD 3A54 A753 EA6F |
From: Jeff D. <jd...@ad...> - 2003-10-29 18:17:30
|
Jam...@ho... said: > Yes, but I will argue that having the offsets directly in the header > rather than the __u32 alignment; would seem to make more sense, the > offsets are what are needed to compute where in the file to read/mmap As far as calculating offsets, the information content is the same. Putting offsets in there strikes me as being a step in the direction of turning the COW format into some general, self-describing thing, which I don't want. The alignment field describes the requirement, which an offset field wouldn't, so it seems better from a documentation point of view. > I may be missunderstanding this works, it mmaps in from the device and > then copies to/from the uml buffer, rather than reading/writing from > the uml buffer? > > I think we can't mmap the pages from the device to the buffer address? Yes, we can, and that's exactly what ubd=mmap does. > The read might have the wrong model since any writes to the just read > buffer would be via mmap be copied back to the device. MAP_PRIVATE > notes that it is unspecified if writes to the mmaped area will appear > in the mmaped area, and might end up with SEGV on NORESERVE If the buffer wasn't mapped before, then it is written out to the file before being mapped in again. The mapping is done with MAP_SHARED. > Write would have the same soft of problem in that the mmap should > occur before the data is copied into the buffer not when the ubd > driver is called Again, if the buffer was changed before the map happened, it is written out first. > Save memory on host seems like a good reason., I don't see where write > gains though I'm not sure how well the block layer insulates the driver from a flood of little writes, so that may have been a bogus reason. But, if you can, within a fixed amount of memory, cause the driver to do continuous writes, then mapping is a win because the writes don't touch the host kernel any more. > Actually it just seemed logical to put it in there and for those that > don't need COW use a degenerate header e.g. no bitmap/no data area/ > backing file is written to, or no bitmap/no backing file/data area is > the disk image My claim is that a need for geometry is totally independent of whether you're using COW. So, introducing a geometry needs to be somewhere else. If we stick it in the COW header, someone is going to say that they need geometry, and they have a good reason that they can't use COW. So, we need to come up with something else, and then the geometry in the COW header is useless. > It was interesting, the bookkeeping was a hassle but not too hard > Testing it was a bit of work though This is basically the same problem that the VM system solves. So, I would look at presenting the COW bitmap to the VM system as virtual memory or a file, and have it deal with swapping it in and out. It may be impossible because you can't make high level read-in-a-file-page calls from the driver because of the locks that are already held, but I think it's worth looking at. Jeff |
From: Matt Z. <md...@de...> - 2003-10-28 17:17:41
|
On Tue, Oct 28, 2003 at 01:34:10AM -0800, James McMechan wrote: > Even better, if you hack it well it would also work on host kernels, well > 2.6+ host kernels but DM appears to be the wave of the future, and COW > files on real devices would be sweet. DM is available and actively maintained on 2.4 as well (LVM2 and EVMS 2.x use it there). They already implement snapshots (COW) using device-mapper; the only difference is that they use a different on-disk metadata format to store the bitmap. > This is somewhat backwards in that it stacks the COW file under the ubd > device, but this is pretty much how it has always been done and once the > ubd_kern side is cleaned up putting a equivalent on top via DM should not > make things too complex, I seem to remember booting from DM or worse yet > loopback is a pain. Then later once DM is working nicely we can drop the > COW layer under ubd easily by just replacing the COW_open/close/read/write > with the normal open/close/read/write functions and let DM do all the hard > work, alas not in the 2.4 roadmap, though it does seem like something that > may get backported... Booting from DM is not bad; there is an ioctl interface to get the physical block addresses to give to the boot loader, and a patch for LILO to use it. I don't know whether grub or any non-i386 bootloaders have support yet. -- - mdz |