Goffredo Baroncelli <[email protected]> writes: > On 2017-02-10 23:21, Dale R. Worley wrote: >> Goffredo Baroncelli <[email protected]> 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 _______________________________________________ Findutils-patches mailing list [email protected] https://lists.gnu.org/mailman/listinfo/findutils-patches
