path: root/btrfs-image.c
Commit message (Collapse)AuthorAge
* btrfs-progs: Cleanup for using BTRFS_SETGET_STACK instead of raw convertQu Wenruo2013-08-09
| | | | | | | | | | | | Some codes still use the cpu_to_lexx instead of the BTRFS_SETGET_STACK_FUNCS declared in ctree.h. Also added some BTRFS_SETGET_STACK_FUNCS for btrfs_header and btrfs_super. Signed-off-by: Qu Wenruo <> Signed-off-by: David Sterba <> Signed-off-by: Chris Mason <>
* Btrfs-progs: enhance btrfs-image to restore image onto multiple disksLiu Bo2013-07-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a 'btrfs-image -m' option, which let us restore an image that is built from a btrfs of multiple disks onto several disks altogether. This aims to address the following case, $ mkfs.btrfs -m raid0 sda sdb $ btrfs-image sda image.file $ btrfs-image -r image.file sdc --------- so we can only restore metadata onto sdc, and another thing is we can only mount sdc with degraded mode as we don't provide informations of another disk. And, it's built as RAID0 and we have only one disk, so after mount sdc we'll get into readonly mode. This is just annoying for people(like me) who're trying to restore image but turn to find they cannot make it work. So this'll make your life easier, just tap $ btrfs-image -m image.file sdc sdd --------- then you get everything about metadata done, the same offset with that of the originals(of course, you need offer enough disk size, at least the disk size of the original disks). Besides, this also works with raid5 and raid6 metadata image. Signed-off-by: Liu Bo <> Signed-off-by: Chris Mason <>
* Btrfs-progs: cleanup btrfs-image usageLiu Bo2013-07-03
| | | | | | | A '\n' is missing. Signed-off-by: Liu Bo <> Signed-off-by: Chris Mason <>
* Btrfs-progs: fix misuse of skinny metadata in btrfs-imageLiu Bo2013-07-03
| | | | | | | As for skinny metadata, key.offset stores levels rather than extent length. Signed-off-by: Liu Bo <> Signed-off-by: Chris Mason <>
* Btrfs-progs: make image restore with the original device offsetsJosef Bacik2013-06-19
| | | | | | | | | | | | | | | | | | | | | I noticed a slight problem with btrfs-image, since it was building a chunk tree by setting the physical offset of the stripes to the same as the logical offset it created this problem where the super block was now mapped into the file system differently than it was before. This isn't a huge deal except that we also carry along the free space cache with us, which is setup with the idea that super at physical X is at logical Y. So this would make the free space checker in fsck freak out because it would see that the cache says that the super block is free space, and that the area where it thought the super block was located is in fact used. In the mount case we'd end up overwriting real metadata with backup super blocks. So we need to maintain the physical offsets in our stripes. This is a huge pain because we store the logical bytenrs of all of our metadata. This patch scans the entire image looking for chunk tree blocks and builds an in memory chunk tree so we can write logical blocks to their physical offsets. With this patch we no longer have the problems I described above. Thanks, Signed-off-by: Josef Bacik <> Signed-off-by: Chris Mason <>
* Btrfs-image: add the ability to santize file names when making an imageJosef Bacik2013-06-19
| | | | | | | | | | | | | | | | | | | We've had a few users who wouldn't (or couldn't) provide us btrfs-images because we maintain the file names when making an image. So introduce a sanitize option. There are two uses, one that is fast and the other that is dog slow. The fast way just generates garbage that's equal in length to the original name. The slow way will try and find a crc32c collision for the file name that is also the same length. Finding a crc32c collision for the file name "btrfs-progs" on my box without CPU crc32c support takes a little more than 3 minutes, and a little less than 2 minutes for my box that has CPU crc32c support, so it's a lengthy and CPU intensive process. The idea is that we use -s for most cases, and then only use -ss when we need the file system tree to be somewhat sane. I could probably do a better job about finding collisions, but I'll have to revist that later. Thanks, Signed-off-by: Josef Bacik <> Signed-off-by: Chris Mason <>
* btrfs-image: fix reading the super block on big metadata blocksChris Mason2013-05-03
| | | | | | | btrfs-image is assuming that every metadata block is the same size. The super is a special snowflake though. It's 4K even on 64K filesystems. Signed-off-by: Chris Mason <>
* Btrfs-progs: add an option to btrfs-image to walk the treesJosef Bacik2013-04-23
| | | | | | | | | | | | When working with a user with a broken file system I noticed I wasn't able to read some of the blocks properly from the restored image. This is because his extent tree was corrupt and was missing references to some of the blocks, which means they weren't copied into the image when he generated it. So add a -w option which will walk all of the trees manually and copy them into the image. This way we can run fsck against a complete file system image and fix any bugs in fsck. Thanks, Signed-off-by: Josef Bacik <>
* Btrfs-progs: add skinny metadata support to progs V3Josef Bacik2013-04-23
| | | | | | | | | This fixes up the progs to properly deal with skinny metadata. This adds the -x option to mkfs and btrfstune for enabling the skinny metadata option. This also makes changes to fsck so it can properly deal with the skinny metadata entries. Thanks, Signed-off-by: Josef Bacik <>
* Btrfs-progs: make btrfs-image restore with a valid chunk tree V2Josef Bacik2013-04-09
| | | | | | | | | | | | | | | | | | | | Previously btrfs-image would set a METADUMP flag and would make one big system chunk to cover the entire file system in the super in order to get around the unpleasant business of having to adjust the chunk tree. This meant that you could use the progs stuff on a restored file system, which is great for testing btrfsck and other such things. But we want to be able to run the tree log replay on a file system that is not able to run the tree log replay. So in order to do this we need to fixup the super's chunk array and the chunk tree itself. This is pretty easy since we restore using the logical offsets of the metadata, so we just have to set the chunk items to have 1 stripe and have the stripes point at the primary device and then use the logical offset of the chunk as the physical offset. With this patch I can restore a file system image that had a tree log and mount the file system and have the log be replayed successfully. This patch also gives you the -o option in case you want the old restore way, in the case where we want to make sure the system chunks as they were given to us are correct. Thanks, Signed-off-by: Josef Bacik <>
* Btrfs-progs: make btrfs-image grab the free space cacheJosef Bacik2013-03-21
| | | | | | | | | A lot of tree log replay bugs are because of strange space cache setups, so make btrfs-image scrape the free space cache as well so we can better replicate what a user is seeing if they have a tree log bug or anything related to free space cache. Thanks, Signed-off-by: Josef Bacik <>
* Btrfs-progs: make btrfs-image copy the tree logs if they existJosef Bacik2013-03-21
| | | | | | | | | | Currently btrfs-image doesn't copy the tree logs, which doesn't help me when we're trying to debug log replay bugs. Since we don't have entries in the extent root for the blocks we have to walk down all of the trees in order to copy them. With this patch I can image a file system with a tree log and it works fine. Thanks, Signed-off-by: Josef Bacik <>
* Btrfs-progs: cleanup error handling in btrfs-imageJosef Bacik2013-03-21
| | | | | | | | | We use BUG_ON() everywhere in btrfs-image. When users are going to use this command things are pretty dire, so I'd rather have really good error messages so I know what happened rather than figure out which one of the 20 BUG_ON()'s made the stupid thing exit early. Thanks, Signed-off-by: Josef Bacik <>
* btrfs-progs: free allocated metadump structure on restore failureEric Sandeen2013-03-10
| | | | | | Don't return w/ "metadump" still allocated Signed-off-by: Eric Sandeen <>
* btrfs-progs: fix mdresotre typo in function namesEric Sandeen2013-02-05
| | | | | | | | "mdresotre" sounds like it might be French, but most likely it's a misspelling of mdrestore. Fix it. Signed-off-by: Eric Sandeen <> Signed-off-by: Zach Brown <>
* btrfs-progs: Handle errors returned from open_ctreeDanny Kukawka2013-01-21
| | | | | Signed-off-by: Danny Kukawka <> Signed-off-by: David Sterba <>
* Mixed back reference (FORWARD ROLLING FORMAT CHANGE)Chris Mason2009-06-08
| | | | | | | | | | | | | | | | | This commit introduces a new kind of back reference for btrfs metadata. Once a filesystem has been mounted with this commit, IT WILL NO LONGER BE MOUNTABLE BY OLDER KERNELS. The new back ref provides information about pointer's key, level and in which tree the pointer lives. This information allow us to find the pointer by searching the tree. The shortcoming of the new back ref is that it only works for pointers in tree blocks referenced by their owner trees. This is mostly a problem for snapshots, where resolving one of these fuzzy back references would be O(number_of_snapshots) and quite slow. The solution used here is to use the fuzzy back references in the common case where a given tree block is only referenced by one root, and use the full back references when multiple roots have a reference
* btrfs-image.c: fix return valuesWang Cong2009-01-21
| | | | | | | | - Exit with non-zero when fail; - Don't exit in non-main functions, return. Signed-off-by: WANG Cong <>
* Fix image tool compile warningsyanhai zhu2008-12-02
* Btrfs image toolYan Zheng2008-11-20
This patch adds btrfs image tool. The image tool is a debugging tool that creates/restores btrfs metadump image. Signed-off-by: Yan Zheng <>