summaryrefslogtreecommitdiff
path: root/btrfs-image.c
Commit message (Collapse)AuthorAge
* Btrfs-progs: skip opening all devices with restoreJosef Bacik2015-02-09
| | | | | | | | | | | When we go to fixup the dev items after a restore we scan all existing devices. If you happen to be a btrfs developer you could possibly open up some random device that you didn't just restore onto, which gives you weird errors and makes you super cranky and waste a day trying to figure out what is failing. This will make it so that we use the fd we've already opened for opening our ctree. Thanks, Signed-off-by: Josef Bacik <jbacik@fb.com>
* Btrfs-progs: make restore update dev itemsJosef Bacik2015-02-09
| | | | | | | | When we restore a multi disk image onto a single disk we need to update the dev items used and total bytes so that fsck doesn't freak out and that we get normal results from stuff like btrfs fi show. Thanks, Signed-off-by: Josef Bacik <jbacik@fb.com>
* Btrfs-progs: Introduce metadump_v2Josef Bacik2015-02-09
| | | | | | | | | | The METADUMP super flag makes us skip doing the chunk tree reading which isn't helpful for the new restore since we have a valid chunk tree. But we still want to have a way for the kernel to know that this is a metadump restore so it doesn't do things like verify data checksums. We also want to skip some of the device extent checks in fsck since those will obviously not match. Thanks, Signed-off-by: Josef Bacik <jbacik@fb.com>
* Btrfs-progs: multi-thread btrfs-image restoreJosef Bacik2015-02-09
| | | | | | | | For some reason we only allow btrfs-image restore to have one thread, which is incredibly slow with large images. So allow us to do work with more than just one thread. This made my restore go from 16 minutes to 3 minutes. Thanks, Signed-off-by: Josef Bacik <jbacik@fb.com>
* btrfs-progs: fix btrfs-image overlapping chunksJosef Bacik2015-02-09
| | | | | | | | | | | | | | If you create a metadump from a striped volume you will have chunks that refer to different logical offsets with the same physical offset on different devices. So when we do the restore we just truncate the number of stripes in each chunk item and carry on, which causes problems because we then have chunks that point to the same physical offset for different logical offsets. To handle this problem we keep track of logical extents that overlap on physical extents. Then we go back and remap these extents into different physical extents on the disk we are restoring onto. This makes us actually able to restore a multi disk image onto a single disk and have everything work out properly. Thanks, Signed-off-by: Josef Bacik <jbacik@fb.com>
* Btrfs-progs: read super properly in btrfs-imageJosef Bacik2015-02-09
| | | | | | | | | | | When btrfs-image makes a metadump it'll map all the blocks from their logical address to their physical. This works out fine with the exception of the super block, which is the physical offset. Normally this just works, but if the user has balanced their fs it'll either crash btrfs-image or it'll copy some completely arbitrary data. This forces btrfs-image to read the super directly from the disk. Thanks, Signed-off-by: Josef Bacik <jbacik@fb.com>
* btrfs-progs: read_tree_block() and read_node_slot() cleanup.Qu Wenruo2015-02-02
| | | | | | | | | | | | Allow read_tree_block() and read_node_slot() to return error pointer. This should help caller to get more specified error number. For existing callers, change (!eb) judgmentt to (!extent_buffer_uptodate(eb)) to keep the compatibility, and for caller missing the check, use PTR_ERR(eb) if possible. Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com> Signed-off-by: David Sterba <dsterba@suse.cz>
* btrfs-progs: autoconf: use standard PACKAGE_* macrosKarel Zak2015-01-28
| | | | | | | | | | | | | - use standard PACKAGE_{NAME,VERSION,STRING,URL,...} autoconf macros rather than homemade BTRFS_BUILD_VERSION - don't #include version.h, now the file is necessary for library API only Note that "btrfs version" returns "btrfs-progs <version>" instead of the original confusing "btrfs <version>". Signed-off-by: Karel Zak <kzak@redhat.com> Signed-off-by: David Sterba <dsterba@suse.cz>
* btrfs-progs: drop feature defines from C files, in favour of CFLAGS definesDimitri John Ledkov2015-01-27
| | | | | | | | | | | | | | | | | | | | | | glibc 2.10+ (5+ years old) enables all the desired features: _XOPEN_SOURCE 700, __XOPEN2K8, POSIX_C_SOURCE, DEFAULT_SOURCE; with a single _GNU_SOURCE define in the makefile alone. For portability to other libc implementations (e.g. dietlibc) _XOPEN_SOURCE=700 is also defined. This also resolves Debian bug report filed by Michael Tautschnig - "Inconsistent use of _XOPEN_SOURCE results in conflicting declarations". Whilst I was not able to reproduce the results, the reported fact is that _XOPEN_SOURCE set to 500 in one set of files (e.g. cmds-filesystem.c) generates/defines different struct stat from other files (cmds-replace.c). This patch thus cleans up all feature defines, and sets them at a consistent level. Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747969 Signed-off-by: Dimitri John Ledkov <dimitri.j.ledkov@intel.com> Signed-off-by: David Sterba <dsterba@suse.cz>
* btrfs-progs: Doc: Add explain on 'source' and 'target' for btrfs-image.Qu Wenruo2015-01-21
| | | | | | | | | Add explain on 'source' and 'target', which is somewhat confusing for users who want to restore dumped image. Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com> [reworded texts] Signed-off-by: David Sterba <dsterba@suse.cz>
* btrfs-progs: add mount status check for btrfs-imageGui Hecheng2014-08-22
| | | | | | | | | | | When btrfs-image run on a mounted filesystem, the undergoing fs operations may change what you have imaged a while ago. In this case, give a warning to remind the user that he may not get a consistent image he wants. Signed-off-by: Gui Hecheng <guihc.fnst@cn.fujitsu.com> [tweaked the message] Signed-off-by: David Sterba <dsterba@suse.cz>
* btrfs-progs: limit minimal num of args for btrfs-imageGui Hecheng2014-08-22
| | | | | | | | | | | The btrfs-image requires at least 2 args to run, one for the source dev/file, the other for the target dev/file. This patch depends on patch: btrfs-progs: move the check_argc_* functions into utils.c Signed-off-by: Gui Hecheng <guihc.fnst@cn.fujitsu.com> Signed-off-by: David Sterba <dsterba@suse.cz>
* btrfs-progs: cleanup unnecessary free if malloc fails in btrfs-imageGui Hecheng2014-08-22
| | | | | | | Don't bother free the buffer if the malloc failed. Signed-off-by: Gui Hecheng <guihc.fnst@cn.fujitsu.com> Signed-off-by: David Sterba <dsterba@suse.cz>
* btrfs-progs: fix btrfs-image old_restore fsck failureGui Hecheng2014-08-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Steps to reproduce: # mkfs.btrfs -f <dev1> # btrfs-image <dev1> <image_file> # btrfs-image -r -o <image_file> <dev2> # btrfs check <dev2> btrfs check output: : read block failed check_tree_block : Couldn't read tree root : Couldn't open file system The btrfs-image should not mess with the chunk tree under the old_restore way. The new restore way was introduced by: commit d6f7e3da0dae7b60cb7565f8a47c3b9045c52d1d Btrfs-progs: make btrfs-image restore with a valid chunk tree V2 ... And the following commit enhanced the new restore on the valid chunk tree building stuff: commit ef2a8889ef813ba77061f6a92f4954d047a78932 Btrfs-progs: make image restore with the original device offsets ... But the second commit should not effect the old_restore way since the old_restore way doesn't try to build a valid chunk tree at all. Signed-off-by: Gui Hecheng <guihc.fnst@cn.fujitsu.com> Signed-off-by: David Sterba <dsterba@suse.cz>
* btrfs-progs: use BTRFS_SUPER_INFO_SIZE to replace raw 4096 in btrfs-imageGui Hecheng2014-08-22
| | | | | Signed-off-by: Gui Hecheng <guihc.fnst@cn.fujitsu.com> Signed-off-by: David Sterba <dsterba@suse.cz>
* btrfs-progs: cleanup possible silent failure in btrfs-imageGui Hecheng2014-08-22
| | | | | | | | | | If the malloc above fails, the btrfs-image will exit directly without any error messages. Now just return the ENOMEM errno and let the caller prompt the error message. Signed-off-by: Gui Hecheng <guihc.fnst@cn.fujitsu.com> Signed-off-by: David Sterba <dsterba@suse.cz>
* btrfs-progs: deal with malloc failure in btrfs-imageGui Hecheng2014-08-22
| | | | | | | | Handle the malloc failure for dump_worker in the same way as the restore worker. Signed-off-by: Gui Hecheng <guihc.fnst@cn.fujitsu.com> Signed-off-by: David Sterba <dsterba@suse.cz>
* btrfs-progs: delete invalid output file when btrfs-image failedGui Hecheng2014-08-22
| | | | | | | | When btrfs-image failed to create an image, the invalid output file had better be deleted to prevent being used mistakenly in the future. Signed-off-by: Gui Hecheng <guihc.fnst@cn.fujitsu.com> Signed-off-by: David Sterba <dsterba@suse.cz>
* btrfs-progs: deal with invalid option combinations for btrfs-imageGui Hecheng2014-08-22
| | | | | | | | | | | | For btrfs-image, dump may not come with option '-o' -r may not come with option '-c', '-s', '-w', dev_cnt != 1 -m may not come with dev_cnt < 2 All of the above should be regarded as invalid combinations, and the usage will show up. Signed-off-by: Gui Hecheng <guihc.fnst@cn.fujitsu.com> Signed-off-by: David Sterba <dsterba@suse.cz>
* btrfs-progs: update manpage for btrfs-image with -m option addedGui Hecheng2014-08-22
| | | | | | | The btrfs-image support multiple devices with -m specified. Signed-off-by: Gui Hecheng <guihc.fnst@cn.fujitsu.com> Signed-off-by: David Sterba <dsterba@suse.cz>
* btrfs-progs: cleanup duplicate assignment of variable leaf for btrfs-imageGui Hecheng2014-08-22
| | | | | | | | The value of variable leaf in while loop don't have to be set for every round. Just move it outside. Signed-off-by: Gui Hecheng <guihc.fnst@cn.fujitsu.com> Signed-off-by: David Sterba <dsterba@suse.cz>
* btrfs-progs: Properly size the leafsize field in the mdrestore_struct structAdam Buchbinder2014-08-22
| | | | | | | | | | It's 32 bits as defined in ctree.h, but the struct had it as 64 bits. Found using MemorySanitizer. Signed-off-by: Adam Buchbinder <abuchbinder@google.com> Reviewed-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com> Signed-off-by: David Sterba <dsterba@suse.cz>
* btrfs-image: Fix a data race in build_chunk_tree.Adam Buchbinder2014-08-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A mdrestore_struct was being written to without its mutex being held. This race was found with ThreadSanitizer; the relevant part of the report looks like this: WARNING: ThreadSanitizer: data race (pid=18828) Write of size 8 at 0x7fffffc3d088 by main thread: #0 build_chunk_tree .../btrfs-progs/btrfs-image.c:2233 #1 __restore_metadump .../btrfs-progs/btrfs-image.c:2294 #2 restore_metadump .../btrfs-progs/btrfs-image.c:2345 #3 main .../btrfs-progs/btrfs-image.c:2545 Previous read of size 8 at 0x7fffffc3d088 by thread T1 (mutexes: write M0): #0 restore_worker .../btrfs-progs/btrfs-image.c:1636 Location is stack of main thread. Mutex M0 created at: #0 pthread_mutex_init ??:0 #1 mdrestore_init .../btrfs-progs/btrfs-image.c:1766 #2 __restore_metadump .../btrfs-progs/btrfs-image.c:2286 #3 restore_metadump .../btrfs-progs/btrfs-image.c:2345 #4 main .../btrfs-progs/btrfs-image.c:2545 Thread T1 (tid=18830, running) created by main thread at: #0 pthread_create ??:0 #1 mdrestore_init .../btrfs-progs/btrfs-image.c:1784 #2 __restore_metadump .../btrfs-progs/btrfs-image.c:2286 #3 restore_metadump .../btrfs-progs/btrfs-image.c:2345 #4 main .../btrfs-progs/btrfs-image.c:2545 Signed-off-by: Adam Buchbinder <abuchbinder@google.com> Signed-off-by: David Sterba <dsterba@suse.cz>
* Btrfs-progs: btrfs-image: don't call pthread_join on IDs not presentRakesh Pandit2014-04-22
| | | | | | | | | | | | | | | | If pthread_create fails in mdrestore_init, then number of threads created could be less then num of threads option. Hence pass number of successful pthread_create calls to mdrestore_destroy, so that we don't call pthread_join on IDs not present when pthread_create fails. metadump_init already had this fixed, but repeats code from metadump_destroy. Reuse metadump_destroy by passing number of threads created (successful pthread_create calls) and save repeated cleaup code. Had to move metadump_destroy before metadump_init for obvious reasons. Signed-off-by: Rakesh Pandit <rakesh@tuxera.com> Signed-off-by: David Sterba <dsterba@suse.cz>
* Btrfs-progs: remove unused variable and update btrfs-image man pageRakesh Pandit2014-03-21
| | | | | | | | | | | | | | | | | | | | | | | | Remove unused variable in btrfs-image.c (update_super) and update man page documentation about -r option. Running btrfsck on a restored image produces missing chunk information. This is because by default, btrfs-image fixes up chunk tree to use 1 stripe pointing to the primary device. This in turns results in btrfsck making some noise. $ ./mkfs.btrfs /dev/sdb2 -f $ ./btrfs-image /dev/sdb2 btrfs_image_output $ ./btrfs-image -r btrfs_image_output disk-image $ ./btrfsck disk-image Device extent[1, 29360128, 8388608] didn't find the relative chunk. Device extent[1, 1111490560, 1073741824] didn't find the relative chunk. Ideally btfsck should be updated to reflect this default behavior and not through these messages, but it isn't harmful and can be done later. Signed-off-by: Rakesh Pandit <rakesh@tuxera.com> Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <clm@fb.com>
* btrfs-progs: don't remove BTRFS_BLOCK_GROUP_DUP in chunk typeRakesh Pandit2014-03-21
| | | | | | | | | | | | | | | | | | | | | | | | | | During restoring of image (-r using btrfs-image) we zero out RAID profile in chunk type but forget to save BTRFS_BLOCK_GROUP_DUP if present. This results in some false messages being printed by btrfsck. $ ./mkfs.btrfs /dev/sdb2 -f $ ./btrfs-image /dev/sdb2 btrfs_image_output $ ./btrfs-image -r btrfs_image_output disk-image $ ./btrfsck disk-image Checking filesystem on disk-image UUID: e644be2d-7701-4bd4-8804-7487f560d2a7 checking extents Chunk[256, 228, 20971520]: length(8388608), offset(20971520), type(2) mismatch with block group[20971520, 192, 8388608]: offset(8388608), objectid(20971520), flags(34) Chunk[256, 228, 29360128]: length(1073741824), offset(29360128), type(4) mismatch with block group[29360128, 192, 1073741824]: offset(1073741824), objectid(29360128), flags(36) Block group[20971520, 8388608] (flags = 34) didn't find the relative chunk. Block group[29360128, 1073741824] (flags = 36) didn't find the relative chunk. Even though ./btrfsck on /dev/sdb2 seemed fine. This is due to type mismatch above and type mismatch occured because we zero'ed out BTRFS_BLOCK_GROUP_DUP while handling chunk trees. Signed-off-by: Rakesh Pandit <rakesh@tuxera.com> Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <clm@fb.com>
* Btrfs-progs: switch to arg_strtou64() part2Wang Shilong2014-03-21
| | | | | | Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com> Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <clm@fb.com>
* btrfs-progs: use stripe_len define hereAnand Jain2014-01-31
| | | | | | Signed-off-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <clm@fb.com>
* Btrfs-progs: rework open_ctree to take flags, add a new one V2Josef Bacik2013-11-07
| | | | | | | | | | | So I needed to add a flag to not try to read block groups when doing --init-extent-tree since we could hang there, but that meant adding a whole other 0/1 type flag to open_ctree_fs_info. So instead I've converted it all over to using a flags setting and added the flag that I needed. This has been tested with xfstests and make test. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* btrfs-progs: free eb in fixup_chunk_tree_block()Zach Brown2013-10-16
| | | | | | | | This was found by static analysis. Signed-off-by: Zach Brown <zab@redhat.com> Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* btrfs-progs: don't overflow read buffer in imageZach Brown2013-10-16
| | | | | | | | | | search_for_chunk_blocks() allocates a fixed-size buffer and then reads arbitrary u32 sized buffers in to it. Instead let's fail if the item is bigger than the buffer. This was found by static analysis. Signed-off-by: Zach Brown <zab@redhat.com> Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* btrfs-progs: don't overrun name in find-collisionsZach Brown2013-10-16
| | | | | | | | | find_collision() allocates name_len bytes for its sub array so the index must be less than name_len. This was found by static analysis. Signed-off-by: Zach Brown <zab@redhat.com> Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* btrfs-progs: drop unused parameter from btrfs_item_nrRoss Kirk2013-10-16
| | | | | | | | | | Remove unused eb parameter from btrfs_item_nr, unused since introduced in 7777e63b425f1444d2472ea05a6b2b9cf865f35b Signed-off-by: Ross Kirk <ross.kirk@gmail.com> Reviewed-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* btrfs-progs: fix -Wmissing-noreturnChris West (Faux)2013-10-16
| | | | | | Signed-off-by: "Chris West (Faux)" <git@goeswhere.com> Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* btrfs-progs: free local variable buf upon unsuccessful returnsGui Hecheng2013-10-16
| | | | | | | | | The variable "buf" passed into find_collision() as parameter "name" should be freed on unsuccessful returns. Signed-off-by: Gui Hecheng <guihc.fnst@cn.fujitsu.com> Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* Btrfs-progs: fix magic return value in btrfs-imgae.cWang Shilong2013-10-16
| | | | | | Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com> Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* btrfs-progs: drop unused parameter from btrfs_release_pathEric Sandeen2013-09-03
| | | | | | | | | | | | | | | Port of commit b3b4aa7 to userspace. parameter tree root it's not used since commit 5f39d397dfbe140a14edecd4e73c34ce23c4f9ee ("Btrfs: Create extent_buffer interface for large blocksizes") This gets userspace a tad closer to kernelspace by removing this unused parameter that was all over the codebase... Signed-off-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* Btrfs-progs: sanitize xattrs when we specify sanitizationJosef Bacik2013-09-03
| | | | | | | | | | | Alexandre pointed out that his xattrs have sensitive information in them as well, so fix btrfs-image to zero out the data part of xattrs that we find. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com> Reviewed-by: Filipe Manana <fdmanana@gmail.com> Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* 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 <quwenruo@cn.fujitsu.com> Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* 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 <bo.li.liu@oracle.com> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* Btrfs-progs: cleanup btrfs-image usageLiu Bo2013-07-03
| | | | | | | A '\n' is missing. Signed-off-by: Liu Bo <bo.li.liu@oracle.com> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* 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 <bo.li.liu@oracle.com> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* 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 <jbacik@fusionio.com> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* 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 <jbacik@fusionio.com> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* 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 <chris.mason@fusionio.com>
* 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 <jbacik@fusionio.com>
* 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 <jbacik@fusionio.com>
* 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 <jbacik@fusionio.com>
* 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 <jbacik@fusionio.com>
* 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 <jbacik@fusionio.com>