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 will use BTRFS_SUBVOL_NAME_MAX.. its only theoretical > as most of the devices path are well below 4k IMO. So its a good > trade off than other solutions like.. (just for the understanding), > > - Update add device code as well to use btrfs_ioctl_vol_args_v2 > Which means we need to introduce BTRFS_IOC_ADD_DEV_V2 (system > PATH_MAX is 4096). > > OR > > - Create new btrfs_ioctl_vol_args_v3 with name[BTRFS_PATH_NAME_MAX+1] > (instead of name[BTRFS_SUBVOL_NAME_MAX+1]) and BTRFS_IOC_RM_DEV_V2 > will be the only consumer of btrfs_ioctl_vol_args_v3 as of now.
I'd rather not introduce any new structures or ioctls, the problem seems to be marginal. As mentioned, paths are way shorter than 4k. A symlink can be used as a workaround. We can document that. The use of BTRFS_SUBVOL_NAME_MAX is confusing for devices, we can do #define BTRFS_DEVICE_PATH_MAX BTRFS_SUBVOL_NAME_MAX -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
