On Fri, Jul 30, 2021 at 8:33 AM Qu Wenruo <quwenruo.btrfs@xxxxxxx> wrote: > > > > On 2021/7/30 下午1:25, Qu Wenruo wrote: > > > > > > On 2021/7/30 上午10:36, NeilBrown wrote: > >> > >> I've been pondering all the excellent feedback, and what I have learnt > >> from examining the code in btrfs, and I have developed a different > >> perspective. > > > > Great! Some new developers into the btrfs realm! > > > >> > >> Maybe "subvol" is a poor choice of name because it conjures up > >> connections with the Volumes in LVM, and btrfs subvols are very different > >> things. Btrfs subvols are really just subtrees that can be treated as a > >> unit for operations like "clone" or "destroy". > >> > >> As such, they don't really deserve separate st_dev numbers. > >> > >> Maybe the different st_dev numbers were introduced as a "cheap" way to > >> extend to size of the inode-number space. Like many "cheap" things, it > >> has hidden costs. > > Forgot another problem already caused by this st_dev method. > > Since btrfs uses st_dev to distinguish them its inode name space, and > st_dev is allocated using anonymous bdev, and the anonymous bdev poor > has limited size (much smaller than btrfs subvolume id name space), it's > already causing problems like we can't allocate enough anonymous bdev > for each subvolume, and failed to create subvolume/snapshot. > How about creating a major dev for btrfs subvolumes to start with. Then at least there is a possibility for administrative reservation of st_dev values for subvols that need persistent <st_dev;st_ino> By default subvols get assigned a minor dynamically as today and with opt-in (e.g. for small short lived btrfs filesystems), the unified st_dev approach can be used, possibly by providing an upper limit to the inode numbers on the filesystem, similar to xfs -o inode32 mount option. Thanks, Amir.
