> >> I brought up the 32-bit inode limit because Alexey was using this as >> an argument not to move ahead with merging the largedir feature. Now >> that I understand his concerns are also based around Lustre, and the >> fact that we are inserting into the hash tree effectively randomly, >> that *is* a soluble problem for Lustre, if it has control over the >> directory names which are being stored in the MDS file. For example, >> if you are storing in this gargantuan MDS directory file names which >> are composed of the 128-bit Lustre FileID, we could define a new hash >> type which, if the filename fits the format of the Lustre FID, parses >> the filename and uses the low the 32-bit object ID concatenated with >> the low-32 bits of the sequence id (which is used to name the target). > > No, the directory tree for the Lustre MDS is just a regular directory > tree (under "ROOT/" so we can have other files outside the visible > namespace) with regular filenames as with local ext4. The one difference > is that there are also 128-bit FIDs stored in the dirents to allow readdir > to work efficiently, but the majority of the other Lustre attributes > are stored in xattrs on the inode. To make picture clean. OST side is regular FS with 32 directories where a stripe objects is live. With current 4G inodes limit each directory will filled with up 100k regular files. Files allocated in batch, up to 20k files per batch. Allocated object used on MDT side to make mapping between metadata objects and data for such file. I worry about it part, not about MDT. these directories have a large number creations/unlinks and performance degradation started after 3M-5M creations/unlinks. With Large dir feature i think this performance problems may deeper. Alexey
