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

[address@hidden]

>----Messaggio originale----
>Da: address@hidden
>Data: 13/02/2017 0.23
>A: <address@hidden>
>Cc: <address@hidden>, <address@hidden>, 
<address@hidden
org>
>Ogg: Re: [Findutils-patches] [PATCH] find memory leak
>
>Goffredo Baroncelli <address@hidden> writes:
>> On 2017-02-10 23:21, Dale R. Worley wrote:
>>> Goffredo Baroncelli <address@hidden> writes:
>>>>> 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....
>>>
>>> Isn't the snapshot identifier currently mapped to the minor device
>>> number?  And aren't those limited to 8 bits?
>>
>> No, they have a uint64 as identifier....
>> In mailing list some suggested to not make more than 300 snapshots in
>> order to avoid bad performance. But this limit is doable.
>>
>> Anyway, in 32 bit mode, the inode is 32 bit too. So leaving only 24
>> bit for the file inode means that you cannot have more than 24millions
>> of files. I not sure that this limits would be acceptable today.
>
>Given the behavior that's been reported, it seems that btrfs identifies
>files by i-node number (e.g., 32 bits) and the minor device number
>(which seems to still be 8 bits).  And from your discussion, it seems
>that the "same" file across snapshots keeps the same i-node number.  So
>the minor number somehow identifies the snapshot in question.  Exacly
>how those two numbers identify the full 64-bit snapshot number, I don't
>know.

The subvolume/snapshot identifier is not related to the inode number and/or
device-id. On the best of my knowledge the api to accessing this kind of
information is btrfs specific. I have to check, but IIRC this number is
obtained searching it on the raw-disk (e.g. no api nor ioctl...) through the
filesystem metadata structures (!).

In order to avoid further misunderstanding: the device-id showed in
/proc/self/mouninfo are sequentially allocated at run time after the mount. 
The
subvolume/snapshot-id are allocated during the subvolume/snapshot creation;
these id are stored on the disk, the former ones aren't.

>
>But you have a point that moving the 8-bit minor number into the i-node
>number in a 32-bit system would cramp things.  (I have a fairly small
>system, but it already uses 0.6M inodes on one file system.)
>
>Dale