Re: [Findutils-patches] [PATCH] find memory leak

[Goffredo Baroncelli]

On 2017-02-09 17:26, Dale R. Worley wrote:
> Bernhard Voelker <address@hidden> 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