The error message about the unsatisfied argument count is scrolled away
by the full usage string dump. This is not considered a good usability
practice.
This commit switches all direct usage -> return patterns, where the
argument check has no other constraint, eg. dependency on an option.
Signed-off-by: David Sterba <dsterba@suse.com>
Similar to the changes where strerror(errno) was converted, continue
with the remaining cases where the argument was stored in another
variable.
The savings in object size are about 4500 bytes:
$ size btrfs.old btrfs.new
text data bss dec hex filename
805055 24248 19748 849051 cf49b btrfs.old
804527 24248 19748 848523 cf28b btrfs.new
Signed-off-by: David Sterba <dsterba@suse.com>
btrfs_next_extent_item() looks for BTRFS_EXTENT_ITEM_KEY and
BTRFS_METADATA_KEY, which are the types we're looking for.
Signed-off-by: James Harvey <jamespharvey20@gmail.com>
Reviewed-by: Su Yue <suy.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Just to keep the 1st paramter the same as kernel.
We can also save a few lines since the parameter is shorter now.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Large numbers like (1024 * 1024 * 1024) may cost reader/reviewer to
waste one second to convert to 1G.
Introduce kernel include/linux/sizes.h to replace any intermediate
number larger than 4096 (not including 4096) to SZ_*.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
I have a valid btrfs image which contains,
...
item 10 key (1103101952 BLOCK_GROUP_ITEM 1288372224) itemoff 15947 itemsize 24
block group used 655360 chunk_objectid 256 flags DATA|RAID5
item 11 key (1103364096 EXTENT_ITEM 131072) itemoff 15894 itemsize 53
extent refs 1 gen 11 flags DATA
extent data backref root 5 objectid 258 offset 0 count 1
item 12 key (1103888384 EXTENT_ITEM 262144) itemoff 15841 itemsize 53
extent refs 1 gen 15 flags DATA
extent data backref root 1 objectid 256 offset 0 count 1
item 13 key (1104281600 EXTENT_ITEM 262144) itemoff 15788 itemsize 53
extent refs 1 gen 15 flags DATA
extent data backref root 1 objectid 257 offset 0 count 1
...
The extent [1103364096, 131072) has length 131072, but if we run
"btrfs-map-logical -l 1103364096 -b $((65536 * 3)) /dev/sda"
it will return mapping info 's of non-existing extents.
It's because it assumes that extents's are contiguous on logical address,
when it's not true, after one loop (cur_logical += cur_len) and mapping
the next extent, we can get an extent that is out of our search range and
we end up with a negative @real_len and printing all mapping infos till
the disk end.
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Reviewed-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Nodesize is used in kernel, the values are always equal. We have to keep
leafsize in headers, similarly the tree setting functions still take and
set leafsize, but it's effectively a no-op.
Signed-off-by: David Sterba <dsterba@suse.com>
This patch add all missing btrfs_close_all_devices() to standalone
tools in btrfs progs, to avoid memory leak.
Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
In btrfs-map-logical main(), strdup() allocates memory to output_file,
but that memory is not freed.
So add missing free() calls before return.
Signed-off-by: Byongho Lee <bhlee.kernel@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.com>
[BUG]
The original map-logical has the following problems:
1) Assert if we pass any tree root bytenr.
The problem is easy to trigger, here the number 29622272 is the bytenr of tree root:
# btrfs-map-logical -l 29622272 /dev/sda6
mirror 1 logical 29622272 physical 38010880 device /dev/sda6
mirror 2 logical 29622272 physical 1111752704 device /dev/sda6
extent_io.c:582: free_extent_buffer: Assertion `eb->refs < 0` failed.
btrfs-map-logical[0x41c464]
btrfs-map-logical(free_extent_buffer+0xc0)[0x41cf10]
btrfs-map-logical(btrfs_release_all_roots+0x59)[0x40e649]
btrfs-map-logical(close_ctree+0x1aa)[0x40f51a]
btrfs-map-logical(main+0x387)[0x4077c7]
/usr/lib/libc.so.6(__libc_start_main+0xf0)[0x7f80a5562790]
btrfs-map-logical(_start+0x29)[0x4078f9]
The problem is that, btrfs-map-logical always use sectorsize as default
block size to call alloc_extent_buffer.
And when it failes to find the block with the same size, it will free
the extent buffer in a incorrect method(Free and create a new one with
refs == 1).
2) Will return map result for non-exist extent.
# btrfs-map-logical -l 1 -b 123456 /dev/sda6
mirror 1 logical 1 physical 1 device /dev/sda6
mirror 1 logical 4097 physical 4097 device /dev/sda6
mirror 1 logical 8193 physical 8193 device /dev/sda6
...
Normally, before bytenr 12582912, there should be no extent as that's
the mkfs time temp metadata/system chunk.
But map-logical will still map them out.
Not to mention the 1 offset among all results.
[FIX]
This patch will rework the whole map logical by the following methods:
1) Always do things inside a extent
Even under the following case, map logical will only return covered
range in existing extents.
|<------ range given ------->|
|<-Extent A->| |<-Extent B->| |<---Extent C->|
Result:
|<-->| |<---------->| |<-->|
So with this patch, we will search extent tree to ensure all operation
are inside a extent before we do some stupid things.
2) No direct call on alloc_extent_buffer function.
That low-level function shouldn't be called at such high level.
It's only designed for low-level tree operation.
So in this patch we will only use safe high level functions avoid such
problem.
[RESULT]
With this patch, no assert will be triggered and better handle on
non-exist extents.
# btrfs-map-logical -l 29622272 /dev/sda6
mirror 1 logical 29622272 physical 38010880 device /dev/sda6
mirror 2 logical 29622272 physical 1111752704 device /dev/sda6
# btrfs-map-logical -l 1 -b 123456 /dev/sda6
No extent found at range [1,123457)
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
This function will write extent content info desired file.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
The new function will print the mapping info of given range
[logical, logical+len).
Note, caller must ensure the ranges are completely inside an extent.
Or btrfs_map_block can return -ENOENT.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Introduce the function to get accurate extent length based on extent
tree search.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
We're not using it anywhere. The best practice is to add enums with
values > 255 for the long options, option index counting is error prone.
Signed-off-by: David Sterba <dsterba@suse.cz>
- 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>
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>
coverity barked out a warning that btrfs-map-logical was storing but
ignoring errors from read_extent_from_disk(). So don't ignore 'em. I
made extent reading errors fatal to match the fatal errors from mapping
mirrors above.
And while we're at it have read_extent_from_disk() return -errno pread
errors instead of -EIO or -1 (-EPERM). The only other caller who tests
errors clobbers them with -EIO.
Signed-off-by: Zach Brown <zab@zabbo.net>
Signed-off-by: David Sterba <dsterba@suse.cz>
Since this patch:
btrfs-progs: move the check_argc_* functions into utils.c
All tools including the independent tools(e.g. btrfs-image, btrfs-convert)
can share the convenience of the check_argc_* functions, so this patch
adopt the argc check functions globally.
Signed-off-by: Gui Hecheng <guihc.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
It complains errno never gets assigned to zero in find-root and since
errno anyway is zero at program started up, lets remove it.
Check "copy is less then zero" isn't possible because strtoull used by
arg_strtou64 wouldn't return -ve number.
Trivial space fixes.
Signed-off-by: Rakesh Pandit <rakesh@tuxera.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
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>
These were mostly in option structs but there were a few gross string
pointer arguments given as 0.
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>
Mark many functions as static, and remove any resulting dead code.
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>
The ret variant in the main function is not changed so even problems
happen, return value is still 0.
The patch fixs the minor bug and return 1 if any problems happen.
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>
If an overflow logical address is passed(for example),the original
code will cause segmentation, this is unfriendly to users,fix it.
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>
David Woodhouse originally contributed this code, and Chris Mason
changed it around to reflect the current design goals for raid56.
The original code expected all metadata and data writes to be full
stripes. This meant metadata block size == stripe size, and had a few
other restrictions.
This version allows metadata blocks smaller than the stripe size. It
implements both raid5 and raid6, although it does not have code to
rebuild from parity if one of the drives is missing or incorrect.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
The right option is 'o' not 'c'. And this tool is used for the block devices
on which there is a btrfs file system, so change "mount_point" to "device".
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
when no output file is given, info_file stays NULL and the following
fprintf segfaults. Default to stdout.
Signed-off-by: Arne Jansen <sensille@gmx.net>
Signed-off-by: Hugo Mills <hugo@carfax.org.uk>
When building on ppc64 I hit a number of warnings in printf:
btrfs-map-logical.c:69: error: format ‘%Lu’ expects type ‘long long
unsigned int’, but argument 4 has type ‘u64’
Fix them.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Hugo Mills <hugo@carfax.org.uk>
