There's an ancient macro btrfs_crc32c which is just wrapping crc32c and
not doing anything else, so we can use the crc helper directly.
Signed-off-by: David Sterba <dsterba@suse.com>
To drop sizes.h from exported headers, replace the few SZ_ constants
from the existing exported headers (ctree.h, send.h). It would be nice
to use them in the long run but right now it would prevent unexporting
the sizes.h file.
Signed-off-by: David Sterba <dsterba@suse.com>
Drop basically all build objects that were entangled due to various
interdependencies and accumulated over the time to libbtrfs.
The commit of shame from 2013 is e5cb128a95 ("btrfs-progs: libify some
parts of btrfs-progs") and let that be a warning how not to do a
library.
The send stream is not yet available in libbtrfsutil, once it will be we
can drop libbtrfs for good.
Signed-off-by: David Sterba <dsterba@suse.com>
Copy the lookup helper and switch the API functions using it. We can
drop dependency on kernel-shared/uuid-tree.c after that.
Signed-off-by: David Sterba <dsterba@suse.com>
There are two functions for resolving subvolume id path, but one is less
convenient and pulls a lot of dependencies. This is
btrfs_list_path_for_root, where the idea is to have the whole tree of
subvolumes and query it as needed.
For simple path resolution we already have btrfs_subvolid_resolve and
it's also in the public API, so we can use it and drop the other one.
This in turn allows to drop btrfs-list.o from build dependencies.
Signed-off-by: David Sterba <dsterba@suse.com>
The two files send-stream and send-utils contain the implementations of
the exported API, which was just for send stream. This was the original
idea. That libbtrfs contains another 40 files was a result of
unclean/missing library design and had to be done that way to resolve
the symbols due to dependencies.
That the same files have been used for both internal and public library
has prevented refactoring and cleanups and was always a risk of breaking
something.
Make separate copy for libbtrfs utils and allow any cleanups and
reduction of number of build objects. The API hasn't changed since the
beginning so there's low risk of missing some fixes from the internal
code.
Signed-off-by: David Sterba <dsterba@suse.com>
Now libbtrfs.a has own list and we can merge $objects and
$shared_objects again. Reformat it now that it's changed.
Signed-off-by: David Sterba <dsterba@suse.com>
Enumerate all the objects required for libbtrfs.a, removing unnecessary
ones on the way
- kernel-lib/radix-tree.o
- kernel-shared/inode-item.o
- libbtrfsutil/stubs.o
There are only a handful of files exported in libbtrfs.sym so the file
is excessively long and most of the code is not necessary. This will be
reduced eventually.
static_libbtrfs_objects need to use the linked shared_objects to avoid
duplication of symbols.
Signed-off-by: David Sterba <dsterba@suse.com>
As preparation to make libbtrfs build standalone and separate, start
with variables simplifications and inlining.
Signed-off-by: David Sterba <dsterba@suse.com>
It will be used to clear received data on RW snapshots that were
received. The function is copied from kernel sources.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
This function lies in the kernel-shared directory and is supposed to be
close to 1:1 copy with its kernel counterpart, yet it takes one extra
argument - root. But this is now unused to simply remove it.
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The function already takes an extent_buffer which has a reference to
the owning filesystem's fs_info. This also brings the function in line
with the kernel's signature.
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
It's not used, so just remove it.
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Add a slightly more convenient way to identify the subvolumes with bad
combination of flags and received uuid.
Signed-off-by: David Sterba <dsterba@suse.com>
Implement safety check when a read-only subvolume is getting switched
to read-write and there's received_uuid set.
This prevents accidental breakage of incremental send use case but
allows user to do the rw change anyway but resets the received_uuid in
that case.
As this is implemented entirely in userspace, it's racy and using the
raw ioctl won't prevent it nor reset the received_uuid. A change in the
ioctl implementation might do that in the future.
Signed-off-by: David Sterba <dsterba@suse.com>
Add option support to force the value change. This allows to do safety
checks by default and warn user that something might break. Using the
force will override that and changing the property should do change
itself and additionally any other changes that could break some
use cases.
Signed-off-by: David Sterba <dsterba@suse.com>
The test misc-tests/038-backup-root-corruption expects a particular
layout of the backup roots but this gets slightly changed due to free
space tree.
$ make TEST=038-backup-root-corruption TEST_ARGS_MKFS='-Rfree-space-tree' TEST_ENABLE_OVERRIDE=true test-misc
Will result in test failure as the expected root is in slot 3 and not 2.
Update the test to try both.
Signed-off-by: David Sterba <dsterba@suse.com>
The enumeration of profiles not available for zoned mode in
btrfs_load_block_group_zone_info was lacking the 3 and 4 copy raid1, add
them.
Signed-off-by: David Sterba <dsterba@suse.com>
There are some send/receive related data not printed in subvol show,
while they're exported by the ioctls. Print them for convenience:
$ btrfs subvol show test
test
Name: test
UUID: dc16dd1b-825f-3245-94a8-557672d6cf85
Parent UUID: -
Received UUID: -
Creation time: 2021-05-17 16:17:14 +0200
Subvolume ID: 19112
Generation: 7730702
Gen at creation: 7730701
Parent ID: 5
Top level ID: 5
Flags: -
Send transid: 0
Send time: 2021-05-17 16:17:14 +0200
Receive transid: 0
Receive time: -
Snapshot(s):
test-snap
Signed-off-by: David Sterba <dsterba@suse.com>
I had to go back to find what BTRFS_ARG_REG is, add a comment for that.
And, search_umounted_fs_uuids() is also to find the seed device, so bring
the related comment above it.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Previously the build would be optional based on what is installed on the
system. Add an option to make this selectable by user, ie. to allow
build without libudev even if it is installed on the system.
For most users and distros libudev dependency should be ok, but we've
had requests to disable various features (embedded, systems with
non-systemd user space base system) so let's do the same.
Signed-off-by: David Sterba <dsterba@suse.com>
The term 'path' is confusing as we normally use it for filesystem paths,
while for multipath it's more related to the physical path by which the
devices are connected (though it also shows up as another path in the
filesystem).
Rename the helper doing the multipath detection so it's clear what path
is meant by that.
Signed-off-by: David Sterba <dsterba@suse.com>
Since libudev doesn't provide a static version of the library for static
build btrfs-progs will have to provide manual fallback. This change does
this by parsing the udev database files hosted at /run/udev/data/.
Under that directory every block device should have a file with the
following name: bMAJ:MIN. So implement the bare minimum code necessary
to parse this file and search for the presence of DM_MULTIPATH_DEVICE_PATH
udev attribute. This could likely be racy since access to the udev
database is done outside of libudev but that's the best that can be
done when implementing this manually and is only for a limited usecase
where static build has to be used.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Currently btrfs-progs will happily enumerate any device which has a
btrfs filesystem on it irrespective of its type. For the majority of
use cases that's fine and there haven't been any problems with that.
However, there was a recent report that in multipath scenario when
running "btrfs fi show" after a path flap (path going down and then
coming back up) instead of the multipath device being show the device
which represents the flapped path is shown. So a multipath filesystem
might look like:
Label: none uuid: d3c1261f-18be-4015-9fef-6b35759dfdba
Total devices 1 FS bytes used 192.00KiB
devid 1 size 10.00GiB used 536.00MiB path /dev/mapper/3600140501cc1f49e5364f0093869c763
/dev/mapper/xxx is actually backed by an arbitrary number of paths,
which in turn are presented to the system as ordinary SCSI devices i.e
/dev/sdX. If a path flaps and a user re-runs 'btrfs fi show' the output
would look like:
Label: none uuid: d3c1261f-18be-4015-9fef-6b35759dfdba
Total devices 1 FS bytes used 192.00KiB
devid 1 size 10.00GiB used 536.00MiB path /dev/sdd
This only occurs on unmounted filesystems as those are enumerated by
btrfs-progs, for mounted filesystem the kernel properly deals only with
the actual multipath device.
Turns out the output of this command is consumed by libraries and the
presence of a path device rather than the actual multipath causes
issues.
Fix this by checking for the presence of DM_MULTIPATH_DEVICE_PATH
udev attribute as multipath path devices are tagged with this attribute
by the multipath udev scripts.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
This is needed for future code which will make btrfs-progs' device
scanning logic a little smarter by filtering out path device in
multipath setups. libudev is added as an optional dependency since the
library doesn't have a static version so making it a hard dependency
means forfeiting static build support. To alleviate this a fallback code
will be added for the static build case which doesn't rely on libudev.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
On images with some damage and mismatching checksum the read operations
will fixup the checksum. This may not be desired and does not make much
sense for read anyway.
Signed-off-by: David Sterba <dsterba@suse.com>
Dave reported a failure of mkfs-test 009 with the free space tree
enabled by default. This is because 009 pre-populates the file system
with a given directory, and for some reason our data allocation path
isn't the same as in the kernel. Fix this by making sure when we
allocate a data extent we remove the space from the free space tree, and
with this our mkfs tests now pass.
Issue: #410
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
