Commit Graph

32 Commits

Author SHA1 Message Date
Eric Sandeen
fd777c3695 btrfs-progs: fix resource leak in scrub_start()
Resolves-Coverity-CID: 1125934
Resolves-Coverity-CID: 1125935
Resolves-Coverity-CID: 1125936
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
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>
2014-01-31 08:22:17 -08:00
Wang Shilong
1878717b75 Btrfs-progs: fix segfault when getting scrub status
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>
2014-01-31 08:22:12 -08:00
Wang Shilong
f8675eb30f Btrfs-progs: add option to skip whether a scrub has started/resumed in userspace
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>
2014-01-31 08:22:11 -08:00
Anand Jain
1ecefced86 btrfs-progs: define BTRFS_UUID_UNPARSE_SIZE for uuid unparse buf size
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>
2014-01-31 08:22:03 -08:00
Wang Shilong
5991043ea4 Btrfs-progs: fix magic return value in cmds-scrub.c
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>
2013-10-16 08:20:42 -04:00
Zach Brown
c17a056f38 btrfs-progs: use NULL instead of 0
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>
2013-09-03 19:41:11 +02:00
Eric Sandeen
fa25b35dcc btrfs-progs: mark static & remove unused from non-kernel code
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>
2013-09-03 19:40:54 +02:00
Qu Wenruo
3ca706a6ee btrfs-progs: Update the usage strings of some cmds
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>
2013-08-09 14:32:37 +02:00
Wang Shilong
c125b7cf43 Btrfs-progs: fix closing of opendir()
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>
2013-08-09 14:32:36 +02:00
Zach Brown
876e3f9380 btrfs-progs: per-thread, per-call pretty buffer
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>
2013-08-09 14:32:33 +02:00
Stefan Behrens
9681f82853 Btrfs-progs: detect when scrub is started twice
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>
2013-08-09 14:32:30 +02:00
Anand Jain
1c41ab9c4a btrfs-progs: fix btrfs scrub start help
a very trivial fix

Signed-off-by: Anand Jain <anand.jain@oracle.com>
2013-04-23 18:56:19 +02:00
Stefan Behrens
4739e7332c Btrfs-progs: make scrub IO priority configurable
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>
2013-03-19 18:23:58 +01:00
Eric Sandeen
7a355379ea btrfs-progs: rework get_fs_info to remove side effects
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>
2013-03-12 17:07:40 +01:00
Eric Sandeen
120fdfafa3 btrfs-progs: don't open-code mountpoint discovery in scrub cancel
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>
2013-03-12 16:48:10 +01:00
Eric Sandeen
c3d5897555 btrfs-progs: fix scrub error return from pthread_mutex_lock
If pthread_mutex_lock() fails it returns the error in ret,
and does not set errno.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
2013-03-10 16:06:37 +01:00
Eric Sandeen
b79d4a217f btrfs-progs: Error handling in scrub_progress_cycle() thread
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>
2013-03-10 16:06:37 +01:00
Eric Sandeen
7b81119b1d btrfs-progs: Issue warnings if ioctls fail in sigint handlers
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>
2013-03-10 16:06:37 +01:00
Eric Sandeen
d310e9cfff btrfs-progs: more scrub cancel error handling
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>
2013-02-27 14:39:39 +01:00
Eric Sandeen
5eaeb577b5 btrfs-progs: fix close of error fd in scrub cancel
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>
2013-02-27 14:39:37 +01:00
Eric Sandeen
a2eec48a8e btrfs-progs: don't use closed fd
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>
2013-02-05 16:09:41 -08:00
Eric Sandeen
6bd3a02fa6 btrfs-progs: don't double-close prg_fd
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>
2013-02-05 16:09:41 -08:00
Zach Brown
f4dc05bf76 btrfs-progs: scrub can leak fd 0
< 0 is returned for errors opening the file, this code could leak fd 0.

Signed-off-by: Zach Brown <zab@redhat.com>
2013-02-05 16:09:40 -08:00
Zach Brown
cb4c601a4e btrfs-progs: fix scrub socket leak
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>
2013-02-05 16:09:40 -08:00
Stefan Behrens
7a69dc4eec Btrfs-progs: make two utility functions globally available
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>
2013-01-30 00:40:35 +01:00
Arne Jansen
133e4520ea Btrfs-progs: bugfix for scrubbing single devices
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>
2013-01-18 18:26:27 +01:00
Lluis Batlle i Rossell
bb0eabc383 btrfs-progs: Fix getopt on arm platforms
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>
2013-01-17 18:27:56 +01:00
Wade Cline
0d5cfddc2c Btrfs-progs: Fix compiler warnings on PPC64
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>
2013-01-17 18:12:57 +01:00
Goffredo Baroncelli
5ef69ff8ec scrub_fs_info( ) file handle leaking
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.
2012-07-03 16:27:46 -04:00
Ilya Dryomov
08b51bd731 Btrfs-progs: allow multi-line command group synopsis
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
2012-02-08 18:55:51 +02:00
Ilya Dryomov
d675085a67 Btrfs-progs: switch all existing commands to a new parser
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>
2012-02-03 21:00:17 +02:00
Ilya Dryomov
4f26833193 Btrfs-progs: rearrange files in the repo
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>
2012-02-03 21:00:17 +02:00