>----Messaggio originale---- >Da: [email protected] >Data: 13/02/2017 0.23 >A: <[email protected]> >Cc: <[email protected]>, <[email protected]>, <ametzler@debian. org> >Ogg: Re: [Findutils-patches] [PATCH] find memory leak > >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.
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 _______________________________________________ Findutils-patches mailing list [email protected] https://lists.gnu.org/mailman/listinfo/findutils-patches
