summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* 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-progs: pass properly formated key to read_fs_rootJosef Bacik2013-06-19
| | | | | | | | | | | We have a BUG_ON() in read_fs_root that expects key->offset == (u64)-1. Restore will just pass in the location it reads out of the inode if it has a subvol reference and pass that in, which doesn't have offset == (u64)-1, so it causes restore blow up. This was reported in bugzilla and this patch fixed the problem. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* Btrfs-progs: make fsck fix certain file extent inconsistenciesJosef Bacik2013-06-19
| | | | | | | | | | | | | | | | | | | | | | The tree log bug I introduced could create inconsistent file extent entries in the file system tree and in some worst cases even create multiple extent entries for the same entry. To fix this we need to do a few things 1) Keep track of extent items that overlap and then pick the one that covers the largest area and delete the rest of the items. 2) Keep track of file extent items that land in extent items but don't match disk_bytenr/disk_num_bytes exactly. Once we find these we need to figure out who is the right ref and then fix all of the other refs to agree. Each of these cases require a complete rescan of all of the extents, so unfortunately if you hit this particular problem the fsck is going to take quite a while since it will likely rescan all the trees 2 or 3 times. With this patch the broken file system a user sent me is fixed and a broken file system that was created by my reproducer is also fixed. 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-progs: add the ability to find mismmatching backrefsJosef Bacik2013-05-10
| | | | | | | | | | | | | An unfortunate side effect to my fsync bug means that anybody who didn't hit the BUG_ON() during tree log replay would have ended up with a corrupted file system. Currently our fsck does not catch this because it just looks for bytenrs for backrefs, it doesn't look at the num_bytes at all. So this patch makes us keep track of how big the backrefs are, since their disk_num_bytes _have_ to match the number of bytes for the actual extent item. With this patch fsck now finds problems with a file system it previously thought was ok. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com>
* Btrfs-progs: sanity check the number of items in a leaf V2Josef Bacik2013-05-10
| | | | | | | | | | I hit this while working on fsck, I got some weird corruption where the number of items was way higher than what would fit in a leaf, which would make things blow up. This fixes the problem by catching it and returning an error so we gracefully exit instead of segfaulting. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* Btrfs-progs: fix compile warnings in i386 machineWang Shilong2013-05-10
| | | | | | | | | | | | | | | | | | | | | | | | See the warnings below: [CC] btrfs-list.o btrfs-list.c: In function 'filter_by_parent': btrfs-list.c:1183:34: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] [CC] cmds-subvolume.o cmds-subvolume.c: In function 'cmd_subvol_show': cmds-subvolume.c:917:5: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] [CC] cmds-restore.o cmds-restore.c: In function 'decompress_lzo': cmds-restore.c:116:10: warning: passing argument 4 of 'lzo1x_decompress_safe' from incompatible pointer type [enabled by default] In file included from cmds-restore.c:31:0: /usr/include/lzo/lzo1x.h:77:1: note: expected 'lzo_uint *' but argument is of type 'size_t *' Reported-by: Russell Coker <russell@coker.com.au> Signed-off-by: Wang Shilong <wangsl-fnst@cn.fujitsu.com> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* btrfs-progs: fix typecast when printing csum valueDavid Sterba2013-05-10
| | | | | | | | | | | | Only the first byte of the wanted csum is printed: checksum verify failed on 65536 found DA97CF61 wanted 6B checksum verify failed on 65536 found DA97CF61 wanted 6BC3870D Also add leading zeros to the format. Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* Btrfs-progs: fixup: add flags to struct btrfs_ioctl_quota_rescan_argsJan Schmidt2013-05-10
| | | | | | | | | The patch set previously sent was sent together with the kernel part, but was not updated as I added some reserved bytes to the ioctl struct for future compatibility. This fixes struct btrfs_ioctl_quota_rescan_args. Signed-off-by: Jan Schmidt <list.btrfs@jan-o-sch.net> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* Btrfs-progs: init free space ctl with proper unitJosef Bacik2013-05-06
| | | | | | | | | | | btrfsck was blowing up when checking the free space cache when we ran xfstests with -l 64k. That is because I was init'ing the free space ctl to whatever the leafsize was, which isn't right for data block groups. With this patch btrfsck no longer complains. This also fixes a tiny little typo in free-space-cache.c I noticed while figuring this problem out. 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: mkfs seg fault for wrong freeAnand Jain2013-05-02
| | | | | | | | | | | | | | With commit 87c09f7 Btrfs-progs: fix memory leaks on cleanup mkfs on multiple dev is ending with segfault at close_all_devices() during kfree(device->name) because mkfs calls btrfs_add_to_fsid, which does not initialize name when dev is added to the list. Signed-off-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* btrfs-progs: Add default rules to MakefileEric Sandeen2013-04-24
| | | | | | | | | | | | | | Add a default rule for any btrfs-$FOO or btrfs-$FOO.static target, allowing it to be built from btrfs-$FOO.c along with all the normal userspace objects. This gets rid of a lot of the cut and pasted rules for each individual command, and as an added bonus makes it easy to build any btrfs-$FOO statically as well, i.e. # make btrfs-convert.static Signed-off-by: Eric Sandeen <sandeen@redhat.com>
* btrfs-progs: standardize tool source filenamesEric Sandeen2013-04-24
| | | | | | | | | | | | | | For any btrfs-$FOO executable, rename the main source file from $FOO.c to to btrfs-$FOO.c This makes it slightly more obvious what's building what, and allows us to write a default rule in the Makefile for these tools. (also add btrfs-calc-size to the list of objects to remove on make clean) Signed-off-by: Eric Sandeen <sandeen@redhat.com>
* Btrfs-progs: add function to map subvol ID to pathStefan Behrens2013-04-23
| | | | | | | | | | | | | | | | Several tools like btrfs-send and btrfs-receive need to map a subvolume ID to a filesystem path. The so far existing methods in btrfs-list.c cause a horrible effort when performing this operation (and the effort is dependent on the number of existing subvolumes with quadratic effort). This commit adds a function that is able to map a subvolume ID to a filesystem path with an effort that is independent of the number of existing subvolumes. In addition to this function, a command line frontend is added as well: btrfs inspect-internal subvolid-resolve <subvolid> <path> Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
* Btrfs-progs: in btrfs-debug-tree, print -1 in key for (u64)-1Stefan Behrens2013-04-23
| | | | | | | | For the objectid and offset field of a key, print -1 instead of the decimal representation of 0xffffffffffffffff. At least for me it is more readable like this. Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
* Btrfs-progs: btrfs-send: free used memory and close fdsStefan Behrens2013-04-23
| | | | | | | | Not important at all since exit() is called afterwards and this is not part of the library. It just makes valgrind happy and thus allows to search for real flaws. Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
* Btrfs-progs: btrfs-crc: support specifying checksum in hexStefan Behrens2013-04-23
| | | | Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
* btrfs-progs: update generation_v2 in btrfs_update_rootEric Sandeen2013-04-23
| | | | | | | | | | | | | | This addresses the same issue as did: 2bd1169 btrfs-progs: root_item generation_v2 is out of sync after btrfsck but rather than optionally updating generation_v2 based on the size of the existing item, increase the size of the item as needed, and unconditionally set generation_v2. This matches the kernel code, and keeping things in sync is a Good Thing. Signed-off-by: Eric Sandeen <sandeen@redhat.com>
* btrfs-progs: set generation_v2 any time we write a new rootEric Sandeen2013-04-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | With this integration branch commit in place: 2bd1169 btrfs-progs: root_item generation_v2 is out of sync after btrfsck I started seeing generation mismatch messages from the kernel at mount time, after a fresh mkfs(!): btrfs: mismatching generation and generation_v2 found in root item... This is because the code which emits the warning does not do so if there is a mismatch but generation_v2 is 0; the above commit began setting generation_v2 to something non-zero, so the warning was emitted. The reason there is a mismatch at all is because mkfs.btrfs calls create_data_reloc_tree(), which copies a root, and then calls btrfs_set_root_generation(), bumping the original copied generation. But nothing updated generation_v2 to match on the way to disk. Fix this by updating generation_v2 in btrfs_insert_root(), as is done in the kernel. This is safe because it's a new root created by userspace, so the btrfs_root_item is guaranteed to be big enough to contain generation_v2. Signed-off-by: Eric Sandeen <sandeen@redhat.com>
* btrfs-progs: fix send-test buildEric Sandeen2013-04-23
| | | | | | | | | | btrfs_read_and_process_send_stream() recently changed its prototype; this gets it building again. 0 means "do not honor the <end cmd>" which was the previous default, before 2bfac02 Btrfs-progs: btrfs-receive optionally honors the end-cmd Signed-off-by: Eric Sandeen <sandeen@redhat.com>
* Btrfs-progs: quota rescanJan Schmidt2013-04-23
| | | | | | | | This adds the quota rescan command to be used if qgroup tracking should get out of sync. Can also be used to query the status of a running rescan operation. Signed-off-by: Jan Schmidt <list.btrfs@jan-o-sch.net>
* Btrfs-progs: make restore deal with really broken file systemsJosef Bacik2013-04-23
| | | | | | | | | | | | | | | | | All we need for restore to work is the chunk root, the tree root and the fs root we want to restore from. So to do this we need to make a few adjustments 1) Make open_ctree_fs_info fail completely if it can't read the chunk tree. There is no sense in continuing if we can't read the chunk tree since we won't be able to translate logical to physical blocks. 2) Use open_ctree_fs_info in restore, and if we didn't load a tree root or fs root go ahead and try to set those up manually ourselves. This is related to work I did last year on restore, but it uses the open_ctree_fs_info instead of my open coded open_ctree. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com>
* Btrfs-progs: fix csum check when extent lands on block groupJosef Bacik2013-04-23
| | | | | | | | | | | | | | | | I was running fsync() tests and noticed that occasionally I was getting a bunch of errors from fsck complaining about csums not having corresponding extents. Thankfully after a few days of debugging this it turned out to be a bug with fsck. The csums were for an extent that started at the same offset as a block group, and were offset within the extent. So the search put us out at the block group item and we just walked forward from there, never finding the actual extent. This is because the block group item key is higher than the extent item key, so it comes first. In order to fix this we need to check and see if we landed on a block group item and take another step backwards to make sure we end up at the extent item. With this patch my reproducer no longer finds csums that don't have matching extent records. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com>
* Btrfs-progs: record errno for ioctl DEFRAG_RANGELiu Bo2013-04-23
| | | | | | In order to sparse exact error message, we need to record errno here. Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
* btrfs-progs: delete unused function btrfs_read_super_deviceAnand Jain2013-04-23
| | | | Signed-off-by: Anand Jain <anand.jain@oracle.com>
* Btrfs-progs: add csum tree checks to btrfsckJosef Bacik2013-04-23
| | | | | | | | | | Looking at a recent user problem I noticed there are weird cases we could possibly be leaving csums in place for an extent we've free'd. I don't think this can happen unless the extent tree is also corrupt, but just in case I'm adding sanity checks to btrfsck. This way we will catch this if it happens normally since xfstests runs btrfsck between each run. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com>
* Btrfs-progs: fix segfault in fsck if the chunk tree is bogusJosef Bacik2013-04-23
| | | | | | | | | I made open_ctree fail if the chunk tree couldn't be open, which means that fsck now segfaults if it can't open the chunk tree. So fix fsck to check the fs_info we get back from open_ctree_fsinfo to make sure it's valid and exit if it's not instead of segfaulting. Thanks, Signed-off-by: Josef Bacik <jbacik@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: use clearer var names in is_ssd()Eric Sandeen2013-04-23
| | | | | | | | | | | | | | is_ssd() uses nondescript variable names; path - to what? disk - it's a dev_t not a disk name, unlike dev, which is a name not a dev_t! Rename some vars to make things hopefully clearer: wholedisk - the name of the node for the entire disk devno - the dev_t of the device we're mkfs'ing sysfs_path - the path in sysfs we ultimately check Signed-off-by: Eric Sandeen <sandeen@redhat.com>
* btrfs-progs: replace blkid_probe_get_wholedisk_devnoEric Sandeen2013-04-23
| | | | | | | | | | | | | | blkid_probe_get_wholedisk_devno() isn't available in some older versions of libblkid. It was used to work around an old bug in blkid_devno_to_wholedisk(), but that has been fixed since 5cd0823 libblkid: fix blkid_devno_to_wholedisk(), present in util-linux 2.17 and beyond. If we happen to be missing that fix, the worst that happens is that we'd fail to detect that a device is an ssd; the upside is that this code compiles on older systems. Signed-off-by: Eric Sandeen <sandeen@redhat.com>
* btrfs-progs: Fix the receive code pathingAlex Lyakas2013-04-23
| | | | | | | | | | | | | The receive code was not distinguishing properly between the mount root and the directory to create the received subvolume in. Also make sure the find_mount_root reports an error if it cannot find a match at all. Reported-by: Robert Buhren <robert@robertbuhren.de> Reported-by: Rory Campbell-Lange <rory@campbell-lange.net> Reported-by: Stefan Priebe - Profihost AG <s.priebe@profihost.ag> Signed-off-by: Alex Lyakas <alex.btrfs@zadarastorage.com> Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
* Btrfs-progs: allow to receive to relative directoriesStefan Behrens2013-04-23
| | | | Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
* Btrfs-progs: remove some unused codeStefan Behrens2013-04-23
| | | | Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
* Btrfs-progs: Fix that BTRFS_FSID_SIZE is used instead of BTRFS_UUID_SIZEStefan Behrens2013-04-23
| | | | | | Both are 16 but it's wrong anyway to use FSID_SIZE for UUIDs. Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
* Btrfs-progs: don't allocate one byte too much each timeStefan Behrens2013-04-23
| | | | | | | | | | str1 + '/' + str2 + '\0' requires a buffer with the size strlen(str1) + strlen(str2) + 2 bytes. str1 + '/' + str2 + '/' + str3 + '\0' requires a buffer with the size strlen(str1) + strlen(str2) + strlen(str3) + 3 bytes. Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
* Btrfs-progs: btrfs-receive optionally honors the end-cmdStefan Behrens2013-04-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A new option is added to btrfs-receive to change the behavior when an <end cmd> is received in the Btrfs send stream. The traditional behavior (which still is the default) is to continue to read the stream until an EOF condition is encountered. If an <end cmd> is received, afterwards either an EOF or a new <stream header> is expected. The new behavior (if the -e option is set on the command line) is to terminate after an <end cmd> is read without the need for an EOF. This allows the stream (e.g. a single TCP stream) to carry additional data or even multiple Btrfs send streams. Old btrfs-send tools used to encode multiple snapshots like this (with 2 snapshots in this example): <stream header> + <sequence of commands> + <end cmd> + <stream header> + <sequence of commands> + <end cmd> + EOF If the new -e option is set, the expected format is like this: <stream header> + <sequence of commands> + <sequence of commands> + <end cmd> The btrfs-send tool is changed in a seperate commit to always use the new format, i.e. to send an <end cmd> only at the end. Note that the currently existing receivers treat <end cmd> only as an indication that a new <stream header> is following. This means, you can just skip the sequence <end cmd> <stream header> without loosing compatibility. As long as an EOF is following, the currently existing receivers handle the new format (if the two new flags are used) exactly as the old one. The goal of changing the semantic of <end cmd> is to be able to use a single stream (one TCP connection) to multiplex a request/response handshake plus Btrfs send streams, all in the same stream. In this case you cannot evaluate an EOF condition as an end of the Btrfs send stream. You need something else, and the <end cmd> is just perfect for this purpose. Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
* Btrfs-progs: fix bug in find_root_genStefan Behrens2013-04-23
| | | | | | A copy & paste error. Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
* Btrfs-progs: small parent_subvol cleanup for cmds-receive.cStefan Behrens2013-04-23
| | | | | | parent_subvol is local to process_snapshot() and not needed outside. Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
* Btrfs-progs: Set the root-id for received subvols in btrfs receiveStefan Behrens2013-04-23
| | | | | | | | | When an entry was added to the subvol search tree, the root_id was always 0 (not set at all) and therefore only the first one was added, all the others had been ignored. This commit sets the root_id before the entry is added. Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
* Btrfs-progs: btrfs-receive: different levels (amount) of debug outputStefan Behrens2013-04-23
| | | | | | | | | There used to be 2 levels of verbose output, now there are 3: - None at all (no -v option given). - Some information about received snapshots / subvolumes (-v option). - Each received command is printed (-vv option). Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
* Btrfs-progs: free memory and close file descriptor in btrfs receiveStefan Behrens2013-04-23
| | | | | | | Nothing really important since this is not part of the library and at the end exit() is called. Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
* Btrfs-progs: cleanup subvol_uuid_search memory in btrfs send/receiveStefan Behrens2013-04-23
| | | | | | Call the cleanup function that was introduced with the other commit. Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
* Btrfs-progs: add a function to free subvol_uuid_search memoryStefan Behrens2013-04-23
| | | | | | | | There was no way to free the memory that was used for the subvol_uuid_search functions. Since this is part of the libbtrfs, add such a cleanup function. Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
* Btrfs-progs: fix a small memory leak in btrfs-list.cStefan Behrens2013-04-23
| | | | | | valgrind found this very obvious issue. Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
* Btrfs-progs: close file descriptor in cmds-send.cStefan Behrens2013-04-23
| | | | | | valgrind found this very obvious issue. Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
* Btrfs-progs: ignore subvols above BTRFS_LAST_FREE_OBJECTIDStefan Behrens2013-04-23
| | | | Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
* btrfs-progs: add quota-related info to usage messagesKoen De Wit2013-04-23
| | | | | | | | | | | Extending usage messages with some info on the quota functionality: - The -i option of "subvol create" and "subvol snapshot" was not documented - The -c option of "qgroup limit" is the default option - The "qouta rescan" command is not yet implemented, while it should be executed after enabling quota on a non-empty filesystem. Signed-off-by: Koen De Wit <koen.de.wit@oracle.com>
* Btrfs-progs: add a free space cache checker to fsck V2Josef Bacik2013-04-23
| | | | | | | | | | | | | In trying to track down a weird tree log problem I wanted to make sure that the free space cache was actually valid, which we currently have no way of doing. So this patch adds a bunch of support for the free space cache code and then a checker to fsck. Basically we go through and if we can actually load the free space cache then we will walk the extent tree and verify that the free space cache exactly matches what is in the extent tree. Hopefully this will always be correct, the only time it wouldn't is if the extent tree is corrupt or we have some sort of awful bug in the free space cache. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com>
* btrfs-progs: do not enable extended refs in mkfs by defaultDavid Sterba2013-04-23
| | | | | | | | | | | This extref feature (lifting the single file hardlink limitation) is new and not backward compatible with older kernels that are still in wide use. For now, use btrfstune to enable the feature, in the future it will be possible to turn it on within mkfs by -O option. Signed-off-by: David Sterba <dsterba@suse.cz>