[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
different.
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 @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
- Re: [Findutils-patches] [PATCH] find memory leak, (continued)
- Re: [Findutils-patches] [PATCH] find memory leak, Goffredo Baroncelli, 2017/02/02
- Re: [Findutils-patches] [PATCH] find memory leak, Bernhard Voelker, 2017/02/02
- Re: [Findutils-patches] [PATCH] find memory leak, Goffredo Baroncelli, 2017/02/03
- Re: [Findutils-patches] [PATCH] find memory leak, Bernhard Voelker, 2017/02/05
- Re: [Findutils-patches] [PATCH] find memory leak, Goffredo Baroncelli, 2017/02/06
- Re: [Findutils-patches] [PATCH] find memory leak, Bernhard Voelker, 2017/02/06
- Re: [Findutils-patches] [PATCH] find memory leak, Goffredo Baroncelli, 2017/02/07
- Re: [Findutils-patches] [PATCH] find memory leak, Bernhard Voelker, 2017/02/07
- Re: [Findutils-patches] [PATCH] find memory leak, Dale R. Worley, 2017/02/08
- Re: [Findutils-patches] [PATCH] find memory leak, Bernhard Voelker, 2017/02/08
- Re: [Findutils-patches] [PATCH] find memory leak,
Goffredo Baroncelli <=
- Re: [Findutils-patches] [PATCH] find memory leak, Bernhard Voelker, 2017/02/08
- Re: [Findutils-patches] [PATCH] find memory leak, Dale R. Worley, 2017/02/09
- Re: [Findutils-patches] [PATCH] find memory leak, Goffredo Baroncelli, 2017/02/09
- Re: [Findutils-patches] [PATCH] find memory leak, Dale R. Worley, 2017/02/10
- Re: [Findutils-patches] [PATCH] find memory leak, Goffredo Baroncelli, 2017/02/12
- Re: [Findutils-patches] [PATCH] find memory leak, Dale R. Worley, 2017/02/12