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