On 28/07/2021 08:01, NeilBrown wrote: > On Wed, 28 Jul 2021, Wang Yugui wrote: >> Hi, >> >> This patchset works well in 5.14-rc3. > > Thanks for testing. > >> >> 1, fixed dummy inode(255, BTRFS_FIRST_FREE_OBJECTID - 1 ) is changed to >> dynamic dummy inode(18446744073709551358, or 18446744073709551359, ...) > > The BTRFS_FIRST_FREE_OBJECTID-1 was a just a hack, I never wanted it to > be permanent. > The new number is ULONG_MAX - subvol_id (where subvol_id starts at 257 I > think). > This is a bit less of a hack. It is an easily available number that is > fairly unique. > >> >> 2, btrfs subvol mount info is shown in /proc/mounts, even if nfsd/nfs is >> not used. >> /dev/sdc btrfs 94G 3.5M 93G 1% /mnt/test >> /dev/sdc btrfs 94G 3.5M 93G 1% /mnt/test/sub1 >> /dev/sdc btrfs 94G 3.5M 93G 1% /mnt/test/sub2 >> >> This is a visiual feature change for btrfs user. > > Hopefully it is an improvement. But it is certainly a change that needs > to be carefully considered. Would this change the behaviour of findmnt? I have several scripts that depend on findmnt to select btrfs filesystems. Just to take a couple of examples (using the example shown above): my scripts would depend on 'findmnt --target /mnt/test/sub1 -o target' providing /mnt/test, not the subvolume; and another script would depend on 'findmnt -t btrfs --mountpoint /mnt/test/sub1' providing no output as the directory is not an /etc/fstab mount point for a btrfs filesystem. Maybe findmnt isn't affected? Or maybe the change is worth making anyway? But it needs to be carefully considered if it breaks existing user interfaces.
