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

[Dale R. Worley]

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.

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