Feature #7059
closedfilestore: avoid leveldb check for xattr when possible
0%
Description
The current FileStore code calls into DBObjectMap for xattrs in many cases unconditionally. This means taht even for objects that have only a few xattrs (that the fs can handle on its own in the inode), we are also hitting leveldb and possibly suffering some slowdown.
Instead, have a small xattr on the fs inode that indicates whether we should look in leveldb at all. I see two ways do to this:
- a flag on the FileStore, set on creation, that indicates whether such xattrs are present.
- if set, only look at DBObjectMap if the xattr is there. otherwise, we can skip it (e.g., on delete).
or
- unconditionally maintain an xattr that indicates whether we spill over into DBObjectMap.
- if not present, assume this is an old store/object and look in DBObjectMap unconditionally (as we do now)
Care would need to be taken that we adjust the attr when we transition from fs-only to fs + DBObjectMap and back.
Other suggestions?
Updated by Haomai Wang over 10 years ago
May I ask about the idea or method?
I also want to reduce redundant calls such as lfn_find() in omap_* functions which degrade performance according to my profile.
Maybe cache some bottleneck check result is better?
Updated by Haomai Wang over 10 years ago
I'm not understand the first way clearly. A flag on the filestore when creating? The flag is associated to FileStore?
Updated by Sage Weil about 10 years ago
- Status changed from New to Resolved
- Source changed from other to Development