[Top][All Lists]

[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: Wed, 8 Feb 2017 19:03:11 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0

On 2017-02-08 17:08, Bernhard Voelker wrote:
> On 02/08/2017 04:49 PM, Dale R. Worley wrote:
>> Bernhard Voelker <address@hidden> writes:
>>>> /proc/self/mountinfo for "/" has 0:18, but stat shows 0:20
>>>> /proc/self/mountinfo for "/boot" has 0:18, but stat shows 0:43
>>> Okay, so for btrfs, the cache function obviously doesn't work based on 
>>> st_dev.
>>> I have to think about how to work around that - it's a pity we have to
>>> single out special file system types ...
>> I'm no expert, but that sounds like an outright error in btrfs (or
>> something).  Should we hack find to compensate for that?
> I also consider this issue in btrfs clearly as a design bug 

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 
So btrfs has to give to every subvolume a different device-id, to differentiate 
files from the original one to the snapshot one.

Unfortunately this is quite simple at "stat(2)" level; it is more difficult to 
obtain at vfs level. This leads to some idiosyncrasies between 
/proc/self/mountinfo and stat(2) 

- along
> others, e.g. you can search for "df not working for btrfs" - but maybe
> we can weaken the problems for find.  The idea is to build the cache
> based on the magic FS number instead of the major/minor.  I'll need
> some quiet minutes on the weekend to think about it.
> Have a nice day,
> Berny

gpg Goffredo Baroncelli <>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

reply via email to

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