On Tue, Feb 25, 2014 at 7:13 PM, Guang <yguang11@xxxxxxxxx> wrote: > Hello, > Most recently when looking at PG's folder splitting, I found that there was > only one sub folder in the top 3 / 4 levels and start having 16 sub folders > starting from level 6, what is the design consideration behind this? > > For example, if the PG root folder is '3.1905_head', in the first level, it > only has one sub folder 'DIR_5' and then one sub folder 'DIR_0', and then > 'DIR_9', under which there are two sub folders 'DIR_1' and 'DIR_9', starting > from which, the next level has 16 sub folders. > > If we start splitting into 16 sub folders in the very first level, we may > potential gain better performance with less dentry lookup (though most > likely the root level been cached). It's an implementation detail of the FileStore (the part of the OSD that stores data in the filesystem). Each of those folders represents an ever-smaller division of the hash space that objects live in. The more PGs you have, the less hash space each one covers, so there's that trail of folders. It's a bit unfortunate, because as you mention it involves more metadata memory caching, but fixing it would require some fairly detailed code in a critical path. The cost of fixing it and the risk of breaking things haven't been worth it yet. -Greg Software Engineer #42 @ http://inktank.com | http://ceph.com _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |