[Top][All Lists]

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

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

From: Dale R. Worley
Subject: Re: [Findutils-patches] [PATCH] find memory leak
Date: Sun, 12 Feb 2017 18:23:30 -0500

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

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.)


reply via email to

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