Bug 126531
Summary: | dlm slowness with shared file IO from multiple nodes | ||
---|---|---|---|
Product: | [Retired] Red Hat Cluster Suite | Reporter: | Dean Jansa <djansa> |
Component: | gfs | Assignee: | Ken Preslan <kpreslan> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Derek Anderson <danderso> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4 | CC: | cmarthal |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-09-14 14:55:42 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Dean Jansa
2004-06-22 21:15:20 UTC
an email from Ken: It's a problem I'd seen once or twice before, but it didn't seem to happen too much and fell to the bottom of the todo pile. But aparently there's something about the way that the DLM threads work that triggers it. The solution to the problem should be part of GFS. Either GFS refuses to respond to a callback for some minimum amount of time after a page fault, or GFS somehow hooks into the scheduling code so the lock isn't released until after the process that faulted gets run for a timeslice. Either way, I think you can blame the bug on me and stop looking at it. :-) I just checked in code that should fix this. Would QA please verify that this solves the problem for them. Thanks. Oops. Didn't mean to close the bug. Looks good now... I ran up to 6 nodes read/write to the shared file and other than the expected slow down as each node was added it seemed OK. Updating version to the right level in the defects. Sorry for the storm. |