On Fri, 17 Feb 2012, Ted Ts'o wrote: > On Fri, Feb 17, 2012 at 10:17:43AM +0100, Lukas Czerner wrote: > > > > So the problem actually is that I have made some assumptions, like for > > example that all data are laid out sequentially (because it is how we > > are creating the qcow2 images with e2image) and possibly more. > > So if your code doesn't work correctly if the block numbers are > monotonically increasing in the qcow2 image, I would *have* to assume > there would be plenty of qemu-generated images files that don't have > this constraint (i.e., suppose you write blocks 10000, 42, 16, and 24 > while running under qemu, presumably that is the order the blocks > would be written and would show up in the qcow2 file). > > Or am I misunderstanding what you are saying here; is it that you are > fairly sure the code will break if the data is not laid out > sequentially, or that you've never tested this case? Hi Ted, as I said I have never tested this. Well, actually I did some very limited testing, but since this was not (and still is not right?) the scope of e2image I did not care enough to test that extensively enough to be sure that it generally works with qcow2 images other than those generated with e2image. But I think it should work. Also I suppose that qemu is being a bit smarter than just writing every extent out so it does not seek madly back and forth when the image is not laid out sequentially. e2image does not do that. Thanks! -Lukas > > Regards, > > - Ted > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
