On Thu, Feb 18, 2016 at 02:59:26PM +0800, Anand Jain wrote:
> #define BTRFS_PATH_NAME_MAX 4087
> #define BTRFS_SUBVOL_NAME_MAX 4039
>
> I am fine with using BTRFS_SUBVOL_NAME_MAX for now. But theoretical
> anomaly is that add-device code path will use BTRFS_PATH_NAME_MAX and
> delete device
On 02/17/2016 06:49 PM, David Sterba wrote:
On Sat, Feb 13, 2016 at 10:01:39AM +0800, Anand Jain wrote:
+ if (vol_args->flags & BTRFS_DEVICE_BY_ID) {
+ ret = btrfs_rm_device(root, NULL, vol_args->devid);
+ } else {
+ vol_args->name[BTRFS_PATH_NAME_MAX]
On Sat, Feb 13, 2016 at 10:01:39AM +0800, Anand Jain wrote:
> + if (vol_args->flags & BTRFS_DEVICE_BY_ID) {
> + ret = btrfs_rm_device(root, NULL, vol_args->devid);
> + } else {
> + vol_args->name[BTRFS_PATH_NAME_MAX] = '\0';
This introduces new ioctl BTRFS_IOC_RM_DEV_V2, which uses enhanced struct
btrfs_ioctl_vol_args_v2 to carry devid as an user argument.
The patch won't delete the old ioctl interface and so kernel remains
backward compatible with user land progs.
Test case/script:
echo "0 $(blockdev --getsz
