Currently, btrfs fi du uses open_file_or_dir(), which tries to open
it's argument with O_RDWR. Because of POSIX semantics, this fails for
non-root users when the file is read-only or is an executable that
is being run currently, or for all users (including root) when the
filesystem is read-only. This results in a somewhat confusing 'Unknown
error -1' message when trying to check such files. Switch to using
open_file_or_dir3() with O_RDONLY passed in the flags, as this avoids
the limitations listed above, and we have no need to write to the files
anyway (and thus shouldn't be opening them writable).
Signed-off-by: Austin S. Hemmelgarn <ahferroin7@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.com>
commit b5e7979 "btrfs-progs: build: extend per-binary objects" allows
the standalone utilities to link against object files shared with the
main binary. However, the btrfs-*.static targets need to be adjusted
to build against the static versions of the common files.
Signed-off-by: Noah Massey <noah.massey@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Currently, open_ctree_fs_info will open whatever path you pass it and try
to interpret it as a BTRFS filesystem. While this is not nessecarily
dangerous (except possibly if done on a character device), it does
result in some rather cryptic and non-sensical error messages when
trying to run certain commands in ways they weren't intended to be run.
Add a check using stat(2) to verify that the path we've been passed is
in fact a regular file or a block device, or a symlink pointing to a
regular file or block device.
This causes the following commands to provide a helpful error message
when run on a FIFO, directory, character device, or socket:
* btrfs check
* btrfs restore
* btrfs-image
* btrfs-find-root
* btrfs inspect-internal dump-tree
stat(2) is used instead of lstat(2), as stat(2) follows symlinks just
like open(2) does, which means we check the same inode that open(2)
opens, and thus don't need special handling for symlinks.
Signed-off-by: Austin S. Hemmelgarn <ahferroin7@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.com>
"qgroup assign" is considered as working without any options
from the following commit.
commit 176aeca9a148 ("btrfs-progs: add getopt stubs where needed")
However, we can pass options to this command.
* actual result
==================================================
# ./btrfs qgroup assign --rescan 0/260 1/261 /btrfs
btrfs qgroup assign: unrecognized option '--rescan'
usage: btrfs qgroup assign [options] <src> <dst> <path>
Assign SRC as the child qgroup of DST
--rescan schedule qutoa rescan if needed
--no-rescan
==================================================
* expected result
==================================================
# ./btrfs qgroup assign --rescan 0/260 1/261 /btrfs
#
==================================================
Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
"inspect-internal subvolid-resolve" doesn't work from the following commit.
commit 176aeca9a148 ("btrfs-progs: add getopt stubs where needed")
It's because 1st argument, subvolid, is also used for the pathname of
filesystem. 2nd argument should be used for this purpose instead.
* actual result
==================================================
# ./btrfs inspect-internal subvolid-resolve 260 /btrfs
ERROR: cannot access '260': No such file or directory
==================================================
* expected result
==================================================
# btrfs inspect-internal subvolid-resolve 260 /btrfs
snap
==================================================
Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
"sub get-default" does't work since the following commit.
commit 176aeca9a148 ("btrfs-progs: add getopt stubs where needed")
* actual result
==================================================
# ./btrfs sub get-default /btrfs
btrfs subvolume get-default: too few arguments
usage: btrfs subvolume get-default <path>
Get the default subvolume of a filesystem
==================================================
* expected result
==================================================
# btrfs sub get-default /btrfs
ID 5 (FS_TREE)
==================================================
Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Test for "btrfs-progs: subvol sync: fix memory corruption, undersized
array", a lot of deleted subvolumes in the 'subvol sync' will not fit
into the array, should result in a glibc report.
Signed-off-by: David Sterba <dsterba@suse.com>
The subvol sync command crashed randomly at the end with
*** glibc detected *** btrfs: double free or corruption (out): 0x00000000006ab040 ***
This is caused by running out of the ids array in case there are more
than 128 subvolumes. The array is increased in steps but does not
account the size of the item, so there was room for 1024 / 8 = 128
subvolume ids.
Fixes: c9f885ec89 ("btrfs-progs: subvol: let sync check only current deletions")
Signed-off-by: David Sterba <dsterba@suse.com>
This aims to decide whether a balance can reduce the number of
data block groups and if it is, this shows the '-dvrange' block
group's objectid.
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
"property" is considered as working without any options
from the following commit.
commit 176aeca9a148 ("btrfs-progs: add getopt stubs where needed")
However, we can pass -t option to this command.
* actual result
==================================================
$ ./btrfs prop list -t f /btrfs
btrfs property list: invalid option -- 't'
usage: btrfs property list [-t <type>] <object>
Lists available properties with their descriptions for the given object.
Please see the help of 'btrfs property get' for a description of
objects and object types.
==================================================
* expected result
==================================================
$ ./btrfs prop list -t f /btrfs
label Set/get label of device.
==================================================
Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com
Signed-off-by: David Sterba <dsterba@suse.com>
This patch introduces new option <devid> for the command
btrfs device delete <device_path|devid>[..] <mnt>
In a user reported issue on a 3-disk-RAID1, one disk failed with its
SB unreadable. Now with this patch user will have a choice to delete
the device using devid.
The other method we could do, is to match the input device_path
to the available device_paths with in the kernel. But that won't
work in all the cases, like what if user provided mapper path
when the path within the kernel is a non-mapper path.
This patch depends on the below kernel patch for the new feature to work,
however it will fail-back to the old interface for the kernel without the
patch
Btrfs: Introduce device delete by devid
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The number of arguments which is allowed to pass became wrong
from the following commit.
commit 176aeca9a148c5e29de0 ("btrfs-progs: add getopt stubs where needed")
* actual result
===========================================================
# ./btrfs prop get /btrfs label
label=foo
# ./btrfs fi label /btrfs
btrfs filesystem label: too few arguments
usage: btrfs filesystem label [<device>|<mount_point>] [<newlabel>]
Get or change the label of a filesystem
With one argument, get the label of filesystem on <device>.
If <newlabel> is passed, set the filesystem label to <newlabel>.
# ./btrfs fi label /btrfs bar
foo
# ./btrfs prop get /btrfs label
label=foo
===========================================================
* expected result
===========================================================
# ./btrfs prop get /btrfs label
label=foo
# ./btrfs fi label /btrfs
foo
# ./btrfs fi label /btrfs bar
# ./btrfs prop get /btrfs label
label=bar
===========================================================
Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Fix the following bug.
================================
# btrfs device scan -- /dev/sdb
ERROR: not a block device: --
================================
It should work as follow.
================================
# ./btrfs device scan -- /dev/sdb
Scanning for Btrfs filesystems in '/dev/sdb'
================================
Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
When 'btrfs device scan' command is invoked, it scans all devices,
check them for btrfs superblock and add devices with btrfs to a list.
Next, each device from the list is passed to kernel where it is handled
in the btrfs_scan_one_device() function. This function can, for example,
return -EBUSY when device contains superblock matched to existing and
mounted filesystem (if this device was pulled out from RAID and
connected again after some time).
btrfs tool stops device scan if any device has been failed to add, so
other existing devices with (possibly) valid FS will never be reached.
Fix this by remove stopping at any failure in the btrfs_register_all_devices(),
just return error count. btrfs_scan_one_device() reports any kind of
error already.
Signed-off-by: Yauhen Kharuzhy <yauhen.kharuzhy@zavadatar.com>
[ initialize err to 0 ]
Signed-off-by: David Sterba <dsterba@suse.com>
For practical purposes teach -t about the human readable names of the
trees in addition to the numerical id. The name syntax is flexible.
Signed-off-by: David Sterba <dsterba@suse.com>
The version information could be useful addition to the dump, print it
before we attempt to open the filesystem.
Signed-off-by: David Sterba <dsterba@suse.com>
PAGE_CACHE_SIZE is hardcoded to 4K in cmds-restore.c. Correct
value should be sector size. Fix this through replacing
hardcoded 4K to sectorsize.
Signed-off-by: Feifei Xu <xufeifei@linux.vnet.ibm.com>
Signed-off-by: David Sterba <dsterba@suse.com>
David Sterba