On Wed, Jan 20, 2010 at 10:28:01AM +0800, Yan, Zheng wrote: > On Wed, Jan 20, 2010 at 12:04 AM, Josef Bacik <jo...@redhat.com> wrote: > > Hello, > > > > btrfs-image would be very helpful for debugging some users problems that we > > can't reproduce ourselves, but every image that i try and re-create with > > btrfs-image makes btrfs panic. This is because we zero out the superblocks > > chunk array and re-create our uuid. This means that we end up not being > > able to > > read the chunk tree on mount, and then even if we could the uuid's of the > > metadata we read back wouldn't match the uuid of the device. The way I've > > fixed > > this is to just spit the metadata back onto the disk exactly the way we got > > it. > > The caveat to this I think is that if we try to image a multi-device setup > > that > > it won't work right unless we have a multi-device setup to restore the image > > onto. I'm not sure if thats the goal or not. This patch makes the single > > disk > > case work fine for me. Let me know what you think. Thanks, > > > > The goal of btrfs-image is create image that can be examined by btrfsck and > btrfs-debug-tree. btrfs-image creates metadata image for btrfs' logical > address > space. So your patch only works for the uncommon case that btrfs' logical > address is mapped to offset of device. >
Ok, but I think it would be helpful to be able to restore the fs onto a device and still be able to use it like a normal fs so we can debug other types of problems. But I don't really care that much so if that wasn't the intended goal I'll find something else to work on. Thanks, Josef -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
