| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
| |
We only freed this allocation in error paths, and leaked
a bit when it went out of scope normally.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
|
| |
|
|
|
|
| |
open() returns a negative fd on failure, not 0.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
|
|
|
This is the user mode part of the device replace patch series.
The command group "btrfs replace" is added with three commands:
- btrfs replace start srcdev|srcdevid targetdev [-Bfr] mount_point
- btrfs replace status mount_point [-1]
- btrfs replace cancel mount_point
Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
|
