open_path_or_dev_mnt() is used to on *mounted* btrfs device or mount
point, when a unmounted btrfs device is passed, errno is set to EINVAL to
info the caller.
If ignore the errno and just print "ERROR: can't access '%s'", end users
will get confused.
This patch will add check for open_path_or_dev_mnt() caller and print
more meaningful error message when a unmounted btrfs device path is
given.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
scrub_progress_cycle thread runs in asynchronous type but locks mutex
while reading shared data. This patch disables cancelability for a
brief time while locks are on so as to make sure they are unlocked
before thread is canceled.
scrub_write_progress gets called from scrub_progress_cycle in
asynchronous thread but cancelability is disabled after mutex is
locked. This patch moves the call to set cancelability type before
mutex lock and makes corresponding changes to labels for error
handling.
Signed-off-by: Rakesh Pandit <rakesh@tuxera.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Threads always use default attributes in all tools, so pthread
attribute objects and their initializations are of no use. Just pass
NULL as attr attribute to pthread_create for default attributes.
Signed-off-by: Rakesh Pandit <rakesh@tuxera.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
If pthread_mutex_lock fails (rare but fix it anyway), don't call
pthread_mutex_unlock on mutex.
Rationale being that if pthread_mutex_lock fails pthread_mutex_unlock
will always fail and overwrite actual error value in err.
Signed-off-by: Rakesh Pandit <rakesh@tuxera.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
Remove the extraneous `to' from `Can't access to X'.
Signed-off-by: Mitchel Humpherys <mitch.special@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
I sometimes get segfault in cmd_scrub_status(), this is because
free_history() forgot to check whether pointer address is valid,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 <clm@fb.com>
I hit a problem that i can not start scrub when i am trying to track
superblock generation mismatch problems.
The fact is that we are trying to check whether we have started a scrub operation
in userspace, this will make us can't start scrub if that record file is damaged
itself. By adding a option to skip that check, everything will be fine.
Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
we use 37 as the allocation size to hold the uuid_unparse, here
it defines BTRFS_UUID_UNPARSE_SIZE for the same.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
There will be four kinds of return value for command "scrub start":
0: scrub dosen't find errors and return success.
1: usage or syntax errors.
3: scrub finds errors and correct all of them.
4: scrub finds errors and some of them are not correctable.
Three kinds of return values for scrub cancel/resume:
0: cancel successfully.
1: usage or syntax errors.
2: cancel a not started or finished scrub.
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>
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>
Update the usage strings of some cmds to keep the them consistent with
the source.
Also some minor changes are done to fit the man page syntax.
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>
valgrind complains open_file_or_dir() causes a memory leak.That is because
if we open a directoy by opendir(), and then we should call closedir()
to free memory.
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>
We don't need callers to manage string storage for each pretty_sizes()
call. We can use a macro to have per-thread and per-call static storage
so that pretty_sizes() can be used as many times as needed in printf()
arguments without requiring a bunch of supporting variables.
This lets us have a natural interface at the cost of requiring __thread
and TLS from gcc and a small amount of static storage. This seems
better than the current code or doing something with illegible format
specifier macros.
Signed-off-by: Zach Brown <zab@redhat.com>
Acked-by: Wang Shilong <wangs.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
Check whether any involved device is already busy running a
scrub. This would cause damaged status messages and the state
"aborted" without the explanation that a scrub was already
running. Therefore check it first, prevent it and give some
feedback to the user if scrub is already running.
Note that if scrub is started with a block device as the
parameter, only that particular block device is checked. It
is a normal mode of operation to start scrub on multiple
single devices, there is no reason to prevent this.
Here is an example:
/mnt2 is the mountpoint of a filesystem.
/dev/sdk and /dev/sdl are the block devices for that filesystem.
case 1:
btrfs scrub start /mnt2
btrfs scrub start /mnt2
-> complain
case 1:
btrfs scrub start /dev/sdk
btrfs scrub start /dev/sdk
-> complain
case 3:
btrfs scrub start /dev/sdk
btrfs scrub start /dev/sdl
-> don't complain
case 4:
btrfs scrub start /dev/sdk
btrfs scrub start /mnt2
-> complain
case 5:
btrfs scrub start /mnt2
btrfs scrub start /dev/sdk
-> complain if the scrub on /dev/sdk is still running.
-> don't complain if the scrub on /dev/sdk is finished, the
status messages will be fine.
Reported-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
The btrfs tool is changed in order to support command line parameters
to configure the IO priority of the scrub tasks. Also the default is
changed. The default IO priority for scrub is the idle class now.
The behavior is the same as when one would type
'ionice ... btrfs scrub start ...' or 'ionice ... btrfs scrub resume ...'
(without this patch applied).
The only reason for adding this to the btrfs tool is that it was not
documented and not obvious that it worked like this, that all internal
scrub tasks inherited the IO priority values of the btrfs tool that is
starting or resuming the scrub operation.
Note that after applying the patch it is no longer possible to set
the IO priority using ionice since the btrfs tool always configures
the priority in order to run in the idle class by default.
Some basic performance measurements have been done with the goal to
measure which IO priority for scrub gives the best overall disk data
throughput. The kernel was configured to use the CFQ IO scheduler
with default configuration and without support for throttling. The
summary is, that the more the disk head movements are avoided, the
faster the overall disk transfer capacity is, which is not really a
big surprise. Therefore it makes sense that the best data throughput
was measured setting the scrub IO priority and the scrub readahead
IO priority to the idle class priority. Running with idle class IO
priority means that scrub and scrub readahead IO is paused while
other tasks access the disk. Doing the tasks one after the other
instead of concurrently avoids many disk head movements. The
overall data throughput of rotating disks is improved this way.
However, if it is desired to have the scrub task done within a
reasonable time, and if at the same time the filesystem is heavily
loaded, the idle IO priority should be avoided. Otherwise the scrub
operation will never take place and thus never terminate.
The best effort IO priority class with the subclass 7 (the lowest
one in the best effort class) is recommended in the case of always
heavily loaded hard disks. If the filesystem is not loaded all the
time and leaves some idle slots for scrub, the idle class IO priority
is recommended. The idle class now is the default if the scrub
operation is started with the btrfs-progs tools.
Note that the patch that sets the scrub readahead IO priority to the
idle class is a seperate patch, this needs to be done in the kernel.
Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
get_fs_info() has been silently switching from a device to a mounted
path as needed; the caller's filehandle was unexpectedly closed &
reopened outside the caller's scope. Not so great.
The callers do want "fdmnt" to be the filehandle for the mount point
in all cases, though - the various ioctls act on this (not on an fd
for the device). But switching it in the local scope of get_fs_info
is incorrect; it just so happens that *usually* the fd number is
unchanged.
So - use the new helpers to detect when an argument is a block
device, and open the the mounted path more obviously / explicitly
for ioctl use, storing the filehandle in fdmnt.
Then, in get_fs_info, ignore the fd completely, and use the path on
the argument to determine if the caller wanted to act on just that
device, or on all devices for the filesystem.
Affects those commands which are documented to accept either
a block device or a path:
* btrfs device stats
* btrfs replace start
* btrfs scrub start
* btrfs scrub status
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
cmd_scrub_cancel had its own mountpoint discovery routine;
just use open_path_or_dev_mnt() for that now.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
consolidate error handling to ensure that peer_fd
is closed on error paths. Add a couple comments
to the error handling after the thread is complete.
Note that scrub_progress_cycle returns negative
errnos on any error.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
The two sigint handlers issue ioctls to clean up, but if
they fail, noone would know. I'm not sure there is
any other error handling to be done at this point, but a
notification seems wise.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
If we request scrub cancel on an unmounted or
non-btrfs device, we still get a "scrub canceled"
success message:
# btrfs scrub cancel /dev/loop1
scrub cancelled
# blkid /dev/loop1
/dev/loop1: UUID="7f586941-1d5e-4ba7-9caa-b35934849957" TYPE="xfs"
Fix this so that if check_mounted_where returns 0
we don't report success.
While we're at it, use perror to report the reason for an open
failure, if we get one.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
If we retry opening the mountpoint and fail, we'll call
close on a filehandle w/ value -1. Rearrange so the
retry uses the same open and same error handling.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
In the case that btrfs scrub cancel is given a device name,
we close the file handle, and then pass it to check_mounted_where()
which eventually preads from that (now closed) fd. Fix the logic
so that we close & re-open the discovered mountpoint properly.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Zach Brown <zab@redhat.com>
If scrub start discovers that scrub is already running,
we need to set prg_fd to -1 before goto out, or we'll
try to close it again in the error path.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Zach Brown <zab@redhat.com>
If connection fails the socket is leaked when the status file is used
instead. Close it to trivially cut down on fd use and to bring down the
noise in static code analysis.
Signed-off-by: Zach Brown <zab@redhat.com>
Two convenient utility functions that have so far been local to scrub are
moved to utils.c.
They will be used in the device stats code in a following commit.
Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
Scrub can be invoked to scrub only a single device of a (mounted) filesystem.
The code determines whether the given path is a mountpoint of a filesystem
by issueing a btrfs-specific ioctl to it. Only in case of EINVAL it assumed
it may be a device, all other errnos just caused it fail, but some devices
(correctly) return ENOTTY. This patch adds this to the error check.
Signed-off-by: Arne Jansen <sensille@gmx.net>
There, 'char' is unsigned, so once assigned '-1' from getopt, it gets
the value 255. Then, it compared to '-1' gives false.
Signed-off-by: Lluis Batlle i Rossell <viric@viric.name>
The kernel uses unsigned long long for u64, but PPC64 uses unsigned
long by default. This results in compilation warnings such as:
print-tree.c:333: warning: format '%llu' expects type 'long long
unsigned int', but argument 4 has type 'u64'
To fix this, the macro __KERNEL__ needs to be defined before including
the file <asm/types.h>. This can be done by defining the macro in
"kerncompat.h" and making it the first included file in the relevant
header files; this fixes the compiler warnings on PPC64.
Reviewed-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Wade Cline <clinew@linux.vnet.ibm.com>
The function scrub_fs_info( ) closes and reopen a file handle
passed as argument, when a caller uses the file handle even after the
call.
The function scrub_fs_info( ) is updated to remove the file handle
argument, and instead uses a private own file handle.
The callers are updated to not pass the argument.
The new infrastructure offloads checking number of arguments passed to a
command to individual command handlers. Fix them up accordingly.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Separate every command group into its own file (cmds_<group>.c) and
rearrange includes. Remove btrfs_cmds.c.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
