summaryrefslogtreecommitdiff
path: root/cmds-scrub.c
Commit message (Collapse)AuthorAge
* btrfs-progs: per-thread, per-call pretty bufferZach Brown2013-08-09
| | | | | | | | | | | | | | | | | 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>
* Btrfs-progs: detect when scrub is started twiceStefan Behrens2013-08-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* btrfs-progs: fix btrfs scrub start helpAnand Jain2013-04-23
| | | | | | a very trivial fix Signed-off-by: Anand Jain <anand.jain@oracle.com>
* Btrfs-progs: make scrub IO priority configurableStefan Behrens2013-03-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* btrfs-progs: rework get_fs_info to remove side effectsEric Sandeen2013-03-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* btrfs-progs: don't open-code mountpoint discovery in scrub cancelEric Sandeen2013-03-12
| | | | | | | 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>
* btrfs-progs: fix scrub error return from pthread_mutex_lockEric Sandeen2013-03-10
| | | | | | | If pthread_mutex_lock() fails it returns the error in ret, and does not set errno. Signed-off-by: Eric Sandeen <sandeen@redhat.com>
* btrfs-progs: Error handling in scrub_progress_cycle() threadEric Sandeen2013-03-10
| | | | | | | | | | | 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>
* btrfs-progs: Issue warnings if ioctls fail in sigint handlersEric Sandeen2013-03-10
| | | | | | | | | 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>
* btrfs-progs: more scrub cancel error handlingEric Sandeen2013-02-27
| | | | | | | | | | | | | | | | | | | 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>
* btrfs-progs: fix close of error fd in scrub cancelEric Sandeen2013-02-27
| | | | | | | | 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>
* btrfs-progs: don't use closed fdEric Sandeen2013-02-05
| | | | | | | | | | 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>
* btrfs-progs: don't double-close prg_fdEric Sandeen2013-02-05
| | | | | | | | | 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>
* btrfs-progs: scrub can leak fd 0Zach Brown2013-02-05
| | | | | | < 0 is returned for errors opening the file, this code could leak fd 0. Signed-off-by: Zach Brown <zab@redhat.com>
* btrfs-progs: fix scrub socket leakZach Brown2013-02-05
| | | | | | | | 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>
* Btrfs-progs: make two utility functions globally availableStefan Behrens2013-01-30
| | | | | | | | 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>
* Btrfs-progs: bugfix for scrubbing single devicesArne Jansen2013-01-18
| | | | | | | | | | 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>
* btrfs-progs: Fix getopt on arm platformsLluis Batlle i Rossell2013-01-17
| | | | | | | 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>
* Btrfs-progs: Fix compiler warnings on PPC64Wade Cline2013-01-17
| | | | | | | | | | | | | | | | 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>
* scrub_fs_info( ) file handle leakingGoffredo Baroncelli2012-07-03
| | | | | | | | | 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.
* Btrfs-progs: allow multi-line command group synopsisIlya Dryomov2012-02-08
| | | | Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
* Btrfs-progs: switch all existing commands to a new parserIlya Dryomov2012-02-03
| | | | | | | 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>
* Btrfs-progs: rearrange files in the repoIlya Dryomov2012-02-03
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>