Since cmd_inspect_rootid() calls btrfs_open_dir(), it rejects a file to
be specified. But as the document says, a file should be supported.
This patch introduces btrfs_open_file_or_dir(), which is a counterpart
of btrfs_open_dir(), to safely check and open btrfs file or directory.
The original btrfs_open_dir() content is moved to btrfs_open() and shared
by both function.
Signed-off-by: Tomohiro Misono <misono.tomohiro@jp.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Currently transaction bugs out insided btrfs_start_transaction in case
of error, we want to lift the error handling to the callers. This patch
adds the BUG_ON anywhere it's been missing so far. This is not the best
way of course. Transforming BUG_ON to a proper error handling highly
depends on the caller and should be dealt with case by case.
Signed-off-by: David Sterba <dsterba@suse.com>
Unless the top level is mounted there is no way to know the
details of all the subvolume. For example:
mount -o subvol=sv1/newsv1 /dev/sdb /btrfs
btrfs su list /btrfs
ID 257 gen 12 top level 5 path sv1
ID 258 gen 9 top level 257 path sv1/snap
ID 259 gen 11 top level 257 path sv1/newsv1
You can't subvol show for sv1 and sv1/snap as its paths aren't
accessible to the user unless the its top level is mounted.
This patch adds two new options to the existing btrfs subvol show
cli. They are --rootid/-r or --uuid/-u, with this now the user will
be able to look for a subvolume using the rootid OR the uuid.
./btrfs su show -r 257 /btrfs
sv1
Name: sv1
UUID: 30129358-c69d-3e4a-a662-29509cc69c95
Parent UUID: -
Received UUID: -
Creation time: 2017-07-11 20:32:57 +0800
Subvolume ID: 257
Generation: 12
Gen at creation: 7
Parent ID: 5
Top level ID: 5
Flags: -
Snapshot(s):
sv1/snap
Signed-off-by: Anand Jain <anand.jain@oracle.com>
[ minor adjustments in the help text ]
Signed-off-by: David Sterba <dsterba@suse.com>
BTW, there is a duplicated definition of btrfs_add_device() in
volumes.h, also remove it.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
There are not performance critical static inlines, we can do the normal
declaration/definition split for various helpers.
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>
The regulare mkfs_btrfs does not anything special about convert and just
passes the arguments. Make that two functions.
Signed-off-by: David Sterba <dsterba@suse.com>
Add a unit mode that will interpret the input number as a signed 64bit,
optionally and not by default for all numbers.
Signed-off-by: David Sterba <dsterba@suse.com>
I got tired of seeing "16.00EiB" whenever btrfs-progs encounters a
negative size value, e.g. during resize:
Unallocated:
/dev/mapper/datamd18 16.00EiB
This version is much more useful:
Unallocated:
/dev/mapper/datamd18 -26.29GiB
Signed-off-by: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
Reviewed-by: Omar Sandoval <osandov@fb.com>
Signed-off-by: David Sterba <dsterba@suse.com>
btrfs_super_block->sys_chunk_array_size is stored as le32 data on
disk. However insert_temp_chunk_item() writes sys_chunk_array_size in
host cpu order. This commit fixes this by using super block access
helper functions to read and write
btrfs_super_block->sys_chunk_array_size field.
Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The refactoring in commit 1c85c3de5a has
broken use of libbtrfs that does not exhibit during build but at the run
time.
Fixes: 1c85c3de5a
Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=600078
Reported-by: Mike Gilbert <floppymaster@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.com>
In get_running_kernel_version() function, we directly pass return
pointer from strtok_r() to string_is_numerical().
Return pointer from strok_r() can be NULL, but string_is_numerical()
can't handle it and will cause NULL pointer derefernces.
Fix it by check if it's a NULL pointer first.
Resolves-Coverity-CID: 1374097
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Enhance the mkfs_features list with the minimum kernel versions that
will allow for turning on compatible and/or safe options.
Signed-off-by: David Sterba <dsterba@suse.com>
Coverity reports (CID 1374096) that there's return value overflow of
ret from get_device_info, but this most likely cannot happen. There's
another minor issue where we use int to iterate over devids.
Signed-off-by: David Sterba <dsterba@suse.com>
The result of the test applies per-filesystem, so we can't simply cache
it. The function hasn't been used yet.
Signed-off-by: David Sterba <dsterba@suse.com>
The toplevel subvolume is special and the other listing code leaves it
out so we have to add several special cases to handle it. There's no
backreference so the path is built artificially. New helper
btrfs_get_toplevel_subvol is a reduced version of btrfs_get_subvol.
There's some information usually missing for the toplevel subvolume, eg.
the uuid or creation info. This has to be fixed on the mkfs side, the
other subvolumes are created by kernel.
Example:
/mnt
Name: <FS_TREE>
UUID: -
Parent UUID: -
Received UUID: -
Creation time: -
Subvolume ID: 5
Generation: 233
Gen at creation: 0
Parent ID: 0
Top level ID: 0
Flags: -
Snapshot(s):
subv1
Signed-off-by: David Sterba <dsterba@suse.com>
The utils helper is not verbose in case of an error, for now the helper
used for subvolume listing will print the error message but not
duplicate the ioctl anymore.
Signed-off-by: David Sterba <dsterba@suse.com>
It seems like bad idea to use a library name (lblkid) within generic
function name. The currently used scanning library is implementation
detail and this detail should be hidden for rest of the code.
Signed-off-by: Karel Zak <kzak@redhat.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
For RAID5, 2 devices setup is just RAID1 with more overhead.
For RAID6, 3 devices setup is RAID1 with 3 copies, not what most user
want.
So warn user at mkfs time for such case, and add explain in man pages.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Misono, Tomohiro
David Sterba
Anand Jain
Qu Wenruo
Zygo Blaxell
Chandan Rajendra
Karel Zak
Domagoj Tršan