Bug 1802451
| Summary: | Optimize posix code to improve file creation | ||
|---|---|---|---|
| Product: | [Community] GlusterFS | Reporter: | Mohit Agrawal <moagrawa> |
| Component: | posix | Assignee: | Mohit Agrawal <moagrawa> |
| Status: | CLOSED UPSTREAM | QA Contact: | |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | mainline | CC: | bugs, pasik |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-03-12 12:28:40 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Solution: To improve the same we followed two ways 1) Keep open fd specific to first level directory(gfid[0]) in .glusterfs, it would force to kernel keep the inodes from all those files in the cache. In case of memory pressure kernel won't uncached first level inodes. We need to open 256 fd's per brick to access the entry faster. 2) Use at based call's(like fstatat, lstatat, readlinkat) access relative path to reduce path based lookup time. After applying the patch https://review.gluster.org/#/c/glusterfs/+/23783/ performance is improved in total operation. This bug is moved to https://github.com/gluster/glusterfs/issues/891, and will be tracked there from now on. Visit GitHub issues URL for further details |
Description of problem: Problem: Before executing a fop in POSIX xlator it builds an internal path based on GFID.To validate the path it call's (l)stat system call and while .glusterfs is heavily loaded kernel takes time to lookup inode and due to that performance drops Version-Release number of selected component (if applicable): How reproducible: Untar kernel tar 100 times from 6 different clients on 24x3 distribute-replicate environment and observe the time Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: