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>
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>
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>
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>
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>
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 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>
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>
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>
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>
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>
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>
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>
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>
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_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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
We are going to unify enabling filesystem features via option -O.
For now, use btrfstune to enable the features.
Signed-off-by: David Sterba <dsterba@suse.cz>
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>
send-test.c links against libbtrfs and uses the send functionality provided
to decode and print a send stream to the console.
66819df "btrfs-progs: add send-test" contained this file when
submitted, but somehow got lost on commit.
[sandeen@redhat.com: Resurrect lost send-test.c from original commit]
Signed-off-by: Mark Fasheh <mfasheh@suse.de>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Trivial patch:
./btrfs-progs/btrfs-select-super -s 0 /dev/sdc
using SB copy 0, bytenr 65536
No valid Btrfs found on /dev/sdc
Open ctree failed
The line 'using..' is confusing which gives an
indication that command is successful
This patch will avoid that when command fails
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Josef Bacik
Wang Shilong
David Sterba
Jan Schmidt
Chris Mason
Anand Jain
Eric Sandeen
Stefan Behrens
Liu Bo
Alex Lyakas
Koen De Wit
Mark Fasheh