On 02/08/2017 07:03 PM, Goffredo Baroncelli wrote: > For sure it is a btrfs bug (see the link which I posted in my other reply). > However this is not a "design bug". There is a rationale behind this choice. > > Because btrfs is capable to writable snapshot, it is possible that in the > same filesystem two files have the same inode-number even tough these > are/became different. > So btrfs has to give to every subvolume a different device-id, to > differentiate files from the original one to the snapshot one.
sorry, IMO it /is/ a design bug if all tools relying on st_dev have to add file system specific code just because that file system consciously breaks the long-known st_dev <-> mountinfo relation. Even latest df(1) does not show the fstype for btfs snapshots (and forget about correct bftrfs file system usage numbers): $ ~/coreutils/src/df -Th /mnt /mnt/.snapshot /mnt/_subvol Filesystem Type Size Used Avail Use% Mounted on /dev/loop1 btrfs 20G 429M 18G 3% /mnt - - 20G 429M 18G 3% /mnt/.snapshot - - 20G 429M 18G 3% /mnt/_subvol After all, it is not (only) a performance issue for find(1), but a general one for the -fstype option for btfs subvolumes and snapshots. $ find /mnt/_subvol | wc -l 2 $ find /mnt/_subvol -fstype btrfs -print | wc -l 0 I don't know more about btrfs and this may sound like a crazy idea, but it would maybe help quite some tools if btrfs would implicitly add an entry to mountinfo for each subvolume/snapshot to avoid such virtual device numbers ... which works e.g. if the admin creates a bind mount for the subvolume to itself (example cont'd): $ mount --bind /mnt/_subvol /mnt/_subvol $ mount --bind /mnt/.snapshot /mnt/.snapshot $ find /mnt/_subvol -fstype btrfs -print | wc -l 1 $ ~/coreutils/src/df -Th /mnt /mnt/.snapshot /mnt/_subvol Filesystem Type Size Used Avail Use% Mounted on /dev/loop1 btrfs 20G 429M 18G 3% /mnt /dev/loop1 btrfs 20G 429M 18G 3% /mnt/.snapshot /dev/loop1 btrfs 20G 429M 18G 3% /mnt/_subvol Have a nice day, Berny _______________________________________________ Findutils-patches mailing list [email protected] https://lists.gnu.org/mailman/listinfo/findutils-patches
