Hello all, and sorry for the long email, What would be the correct way to approach the following problem: I want to implement a filesystem imaging software (not block-based, dd is pretty good there already). Parsing the filesystem structures on disk is not really the problem (ext2/ext3 at the moment) but accessing data "behind" LVM2 is. >From the mailing list archives I found a link to agk's presentation slides on LVM2, which were very helpful, but don't contain enough information in order to do proper lvm structure parsing yet. Source code is the only place where this is documented, right? Anyhow, the question is this: - should I used libdevmapper to access LVM2 data on disk or not? The aim for the imaging software is to be suitable in rescue disks which means that I cannot rely on the kernel having activated any volumes. It is also my plan to support accessing data trough VMDK-layer, so that the actual reading would then be parseVDMK(parseLVM(parseExt())). On the other hand the reading layer would be generic enough to support replaceable mappings. On a related note, if anyone has information on the format of virtual disks that MS is using in virtual PC, it would also be helpful. Does this sound insane or doable? Question being really "how difficult is it to parse LVM2 on disk structures in order to locate blocks" and "how much will the structures change during the lifetime of LVM2"? A related problem is implementing the restoring-portion of the software. Should libdevmapper be used to create new LVM-structures or disk or is it even possible? Or should I just use exec with the existing LVM2 command line tools in order to create the necessary structures? My aim is also to support the incremental backup scenario in which only new data will be stored in the image. In order for this work I'll need to parse the filesystem structures much further that is done in partimage (for example), which only parses fs-stuff enough to determine whether some block should be stored or not. Currently I'm mapping out the difficulty level of this project and might abandon it all-together if it appear to be too complex so additional information is greatly appreciated. ak. _______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
