findutils-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Goffredo Baroncelli
Subject: Re: [Findutils-patches] [PATCH] find memory leak
Date: Thu, 9 Feb 2017 19:16:19 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]