On 2017-02-09 17:26, Dale R. Worley wrote: > Bernhard Voelker <[email protected]> writes: >> 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): > > I agree with Bernhard that btrfs is basically breaking the specification > of /proc/mountinfo. On this point we fully agree. This is a bug, and it responsible of the BTRFS developers to address it; I tried to point out, however, that it is not a *design bug*, but an *implementation bug*. Nothing in the design of btrfs prevents to show in mountinfo the same device-id returned by stat(2). It has only to be implemented. On the basis of Jeff Mahoney's answer [1], it is an activity (more or less) planned.
> Or perhaps the inode > returned in stat() could contain a field to contain the snapshot > identifier along with the "base" i-node number. (I guess we know the > snapshot identifiers don't exceed 255!) A bit more: ~2^64 ... However it is suggested to not make more of few hundreds.... > > Bernhard's suggestion would fix the problem. The problem is very old, and nobody complained (?); I will try to inform the btrfs mailing list hoping to push an update in the kernel side to return the right major/minor in mountinfo > > Dale > -- gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 _______________________________________________ Findutils-patches mailing list [email protected] https://lists.gnu.org/mailman/listinfo/findutils-patches
