Definition of NULL is missing if ioctl.h is included standalone or when
no other include pulls the definition.
Reported-by: Sergei Trofimovich <slyich@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The build fails if ioctl.h is included without kerncompat.h which
defines BUILD_ASSERT, as reported. The proposed patches add kerncompat.h
but I don't want to pull that header via ioctl.h, so the fix will
provide an empty macro instead.
Reported-by: Eric Sandeen <sandeen@redhat.com>
Reported-by: Sergei Trofimovich <slyfox@gentoo.org>
Reported-by: Mikhail Pukhlikov <cynede@gentoo.org>
Signed-off-by: David Sterba <dsterba@suse.com>
The ioctl value of SEND will be different on 32bit userspace and 64bit
kernel due to different pointer type width, that unfortunatelly made it
into the structure definition.
To maintain backward compatibility, we must do it in the 64bit->32bit
way, because we don't have the kernel side workardound like
SET_RECEIVED_SUBVOL has. Changing value of SEND would then break
existing users of the raw ioctl.
The compatibility structure and ioctl should not be used, exists for
documentation, and testing.
Signed-off-by: David Sterba <dsterba@suse.com>
The ioctl value of SET_RECEIVED_SUBVOL will be different on 32bit
userspace and 64bit kernel. This is transparently handled on the kernel
side. We now define the same structure so we can verify the ioctl value.
The defined structure and ioctl should not be used. It is exists only
for testing purposes, documenting the mess and as a warning for the
future.
Signed-off-by: David Sterba <dsterba@suse.com>
All structures that become part of ioctl definition must never change
size. Add the build time checks for that.
Signed-off-by: David Sterba <dsterba@suse.com>
BTRFS_IOC_LOGICAL_INO takes a btrfs_ioctl_logical_ino_args as argument,
not a btrfs_ioctl_ino_path_args. The lines were probably copy/pasted
when the code was written.
Since btrfs_ioctl_logical_ino_args and btrfs_ioctl_ino_path_args have
the same size, the actual IOCTL definition here does not change.
But, it makes the code less confusing for the reader.
Signed-off-by: Hans van Kranenburg <hans.van.kranenburg@mendix.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>
Add the overlapping usage and [usage_min, usage_max] members to the
balance args. The min/max values are interpreted iff the corresponding
flag BTRFS_BALANCE_ARGS_USAGE_RANGE is set.
The minimum boundary is inclusive, maximum is exclusive:
* usage_min <= chunk_usage < usage_max
Signed-off-by: David Sterba <dsterba@suse.com>
Add new balance filter 'stripes=<range>' to process only chunks that are
spread accross given number of chunks.
The range minimum and maximum are inclusive.
Signed-off-by: Gabríel Arthúr Pétursson <gabriel@system.is>
[ reworked a bit to use the range helpers, dropped the single value
for stripes ]
Signed-off-by: David Sterba <dsterba@suse.com>
Add the overlapping limit and [limit_min, limit_max] members to the
balance args. The min/max values are interpreted iff the corresponding
flag BTRFS_BALANCE_ARGS_LIMIT_RANGE is set.
The minimum and maximum are inclusive.
Note that the values are only 32bit, but this should be enough for the
foreseeable future.
Signed-off-by: David Sterba <dsterba@suse.com>
Add includes that let the header files compile or add explicit include
of kerncompat if the uXX types are used.
Signed-off-by: David Sterba <dsterba@suse.cz>
A new dev replace result was introduced by kernel commit
Btrfs: return failure if btrfs_dev_replace_finishing() failed
Make the userspace know about the new result too.
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
If BTRFS_IOC_DEV_REPLACE ioctl failed, args.result usually won't be
updated by the ioctl.
And the arg has been initialized with 0, the result is always 0, which
is BTRFS_IOCTL_DEV_REPLACE_RESULT_NO_ERROR, and the resulting error
message looks confusing:
ERROR: ioctl(DEV_REPLACE_START) failed on "/mnt/btrfs": No such file or directory, no error
But in case there's an internal result returned in future, don't drop
the result completely, instead print dev replace result message only
if the result is updated by a failed ioctl call.
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Add more control to the balance behaviour.
Usage filter may not be finegrained enough and can lead to moving too
many chunks at once. Another example use is in connection with
drange+devid or vrange filters that allow to work with a specific chunk
or even with a chunk on a given device.
The limit filter applies last, the value of 0 means no limiting.
CC: Ilya Dryomov <idryomov@gmail.com>
CC: Hugo Mills <hugo@carfax.org.uk>
Signed-off-by: David Sterba <dsterba@suse.cz>
For btrfs,
Raid5 can't go below 2 devs, not 3;
Raid6 can't go below 3 devs, not 4.
Signed-off-by: Gui Hecheng <guihc.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
A BTRFS_IOC_CLONE_RANGE request with a src_length value of zero has the
effect of cloning all data from src_offset through to end-of-file.
Document this behaviour in the header file for those who (like me)
incorrectly assume that no data is cloned in such a case.
Signed-off-by: David Disseldorp <ddiss@suse.de>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
for now the manual sync up of new ioctls introduced in the btrfs
kernel. For which there wasn't any btrfs-progs patch.
however we might have better idea for the long run.
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>
Subvolume deletion does not do a full transaction commit. This can lead
to an unexpected result when the system crashes between deletion and
commit, the subvolume directory will appear again. Add options to request
filesystem sync after each deleted subvolume or after the last one.
If the command with --commit option finishes succesfully, the
subvolume(s) deletion status is safely stored on the media.
Userspace approach is more flexible than in-kernel. Related discussions:
http://www.spinics.net/lists/linux-btrfs/msg22088.htmlhttp://www.spinics.net/lists/linux-btrfs/msg27240.html
CC: Alex Lyakas <alex.btrfs@zadarastorage.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
Raid5 and raid6 at least need three and foure devices respectively,
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 <chris.mason@fusionio.com>
With -w one can wait for a rescan operation to finish. It can be used when
starting a rescan operation or later to wait for the currently running
rescan operation to finish. Waiting is interruptible.
Signed-off-by: Jan Schmidt <list.btrfs@jan-o-sch.net>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
when user runs command btrfs dev del the raid requisite error if any
goes to the /var/log/messages, its not good idea to clutter messages
with these user (knowledge) errors, further user don't have to review
the system messages to know problem with the cli it should be dropped
to the user as part of the cli return.
to bring this feature created a set of the ERROR defined
BTRFS_ERROR_DEV* error codes and created their error string.
I expect this enum to be added with other error which we might
want to communicate to the user land
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
This commit adds a command line option to enable sending streams
which make use of the new end-cmd semantic if multiple snapshots are
sent back-to-back. The goal is to use the <end cmd> as an indication
to stop reading the input stream. So far, the receiver could only
use EOF to recognize the end.
If the new command line option '-e' is set, this commit requires a
kernel which is able to support the new flags in the send ioctl. New
bits in the flags of the send ioctl will be set which cause EINVAL
on old kernels. However, if the option '-e' is not set, it works
with old and new kernels without any errors or any changed behavior.
This used to be the encoding (with 2 snapshots in this example):
<stream header> + <sequence of commands> + <end cmd> +
<stream header> + <sequence of commands> + <end cmd> + EOF
The new format (if the two new flags are used) is this one:
<stream header> + <sequence of commands> +
<sequence of commands> + <end cmd>
Note that the currently existing receivers treat <end cmd> only as
an indication that a new <stream header> is following. This means,
you can just skip the sequence <end cmd> <stream header> without
loosing compatibility. As long as an EOF is following, the currently
existing receivers handle the new format (if the two new flags are
used) exactly as the old one.
Also note that the kernel interface was changed in a way that is
backward compatible to old btrfs-progs tools. You set one or two bits
in the flags field of the ioctl to enable the new behavior. Old tools
set these flags to zero, thus getting exactly the same as they got
with older kernels. And this is exactly what happens if the new '-e'
option is not set, the new bits in the flags are not set and thus
old kernels and new kernels are both supported.
So what is the benefit of this change? The goal is to be able to use
a single stream (one TCP connection) to multiplex a request/response
handshake plus Btrfs send streams, all in the same stream. In this
case you cannot evaluate an EOF condition as an end of the Btrfs send
stream. You need something else, and the <end cmd> is just perfect
for this purpose.
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 patch set previously sent was sent together with the kernel part, but
was not updated as I added some reserved bytes to the ioctl struct for
future compatibility. This fixes struct btrfs_ioctl_quota_rescan_args.
Signed-off-by: Jan Schmidt <list.btrfs@jan-o-sch.net>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
This adds the quota rescan command to be used if qgroup tracking should get
out of sync. Can also be used to query the status of a running rescan
operation.
Signed-off-by: Jan Schmidt <list.btrfs@jan-o-sch.net>
With this new ioctl(2), we can set/change the label for a mounted file system.
It still does normal process for an umounted file system.
Signed-off-by: Jie Liu <jeff.liu@oracle.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Please find attached a patch to make the new libbtrfs usable from
C++ (at least for the parts snapper will likely need).
Signed-off-by: Arvin Schnell <aschnell@suse.de>
Signed-off-by: Mark Fasheh <mfasheh@suse.de>
The flag and command are synced from kernel to user. Also, this patch adds a
callback for the BTRFS_SEND_C_UPDATE_EXTENT in struct btrfs_send_ops.
read_and_process_cmd() is updated to decode BTRFS_SEND_C_UPDATE_EXTENT and
send the values through the right callback. I did not add a callback
definition to cmds-receive.c as that code never uses
BTRFS_SEND_FLAG_NO_FILE_DATA.
Signed-off-by: Mark Fasheh <mfasheh@suse.de>
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>
"btrfs device stats" is used to retrieve and print the device stats.
"btrfs device stats -z" is used to atomically retrieve, reset and
print the stats.
Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
This command will be used by things like dracut that wish to know very
simply if all of the devices have been added to the kernel cache yet for the
device to be fully mounted. This keeps initrd's from constantly having to
try to mount the file system until it succeeds every time a device is added
to the system. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Gene Czarcinski <gene@czarc.net>
Btrfs send/receive and btrfs props needs this ioctl. This patch
requires a recent kernel with the "Btrfs: use _IOR for
BTRFS_IOC_SUBVOL_GETFLAGS" patch applied.
Signed-off-by: Alexander Block <ablock84@googlemail.com>
two new commands that make use of the new path resolving functions
implemented for scrub, doing the resolving in-kernel. the result for both
commands is a list of files belonging to that inode / logical address.
Signed-off-by: Jan Schmidt <list.btrfs@jan-o-sch.net>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
David Sterba
Hans van Kranenburg
Nicholas D Steeves
Julio Montes
Anand Jain
Gabríel Arthúr Pétursson
David Sterba
Eryu Guan
Gui Hecheng
Arvin Schnell
David Disseldorp
Wang Shilong
Jan Schmidt
Stefan Behrens
Jeff Liu
Mark Fasheh
Josef Bacik
Arne Jansen
Alexander Block
Ilya Dryomov