Bug 1502455
| Summary: | disperse eager-lock degrades performance for file create workloads | |||
|---|---|---|---|---|
| Product: | [Community] GlusterFS | Reporter: | Manoj Pillai <mpillai> | |
| Component: | disperse | Assignee: | Xavi Hernandez <jahernan> | |
| Status: | CLOSED WONTFIX | QA Contact: | ||
| Severity: | high | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 3.12 | CC: | bugs, jahernan, pkarampu | |
| Target Milestone: | --- | Keywords: | Performance, Triaged | |
| Target Release: | --- | |||
| Hardware: | x86_64 | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1502610 (view as bug list) | Environment: | ||
| Last Closed: | 2018-01-11 10:09:15 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: | ||||
| Bug Depends On: | 1502610, 1512460, 1530519 | |||
| Bug Blocks: | ||||
|
Description
Manoj Pillai
2017-10-16 05:22:47 UTC
IMO, a solution that adds a separate option to control eager locking in the case of directories would be acceptable, and probably simple. So the default could be: disperse.dir-eager-lock off: applies to directories disperse.eager-lock on: applies to regular files Would that work? I guess this problem happens when multiple clients are creating files on the same directory, right ? otherwise, eager-locking shouldn't interfere with file creation (in fact it should be faster). In cases where multiple clients access the same directory, then yes, we could keep a separate configuration for this purpose. However, is it really necessary to have it disabled by default ? I think that an scenario where multiple clients are writing to the same directory is less probable than one where all writes to a single directory come from the same client. BTW, I realize that the norm would be to provide performance results as supporting evidence. I'm currently waiting on some systems to become available, so can't do that right away. Will do so as soon as I can. But this problem has been seen multiple times in the past, in customer cases as well as our internal testing, and this bz has been long pending. So decided to go ahead and open it to avoid more delays. (In reply to Xavier Hernandez from comment #2) > I guess this problem happens when multiple clients are creating files on the > same directory, right ? otherwise, eager-locking shouldn't interfere with > file creation (in fact it should be faster). Yes, with multiple clients. But we have seen degradation even when each client is creating its data set in its own private directory. Seemed like there was contention on directories in the path. I've uploaded a patch on branch master (Bug #1502610) to create the new option. I've named the option 'other-eager-lock' since it will control eager locking for entries other than regular files (directories, symbolic links, pipes, ...). For now I've left the default value to 'on', but you can change it via 'gluster volume set' to do tests. Depending on the results, we can decide the final default value. I have built the rpms from the master. Will try it out once I take care of some other work. After some discussion, it was decided that this option won't be backported to 3.12 because it's considered a new feature. It's present on 3.13+. |