Bug 810079 - Handle failures of open fd migration from old graph to new graph
Handle failures of open fd migration from old graph to new graph
Status: CLOSED DUPLICATE of bug 809919
Product: GlusterFS
Classification: Community
Component: core (Show other bugs)
Unspecified All
unspecified Severity medium
: ---
: ---
Assigned To: Amar Tumballi
Depends On:
  Show dependency treegraph
Reported: 2012-04-05 01:35 EDT by Junaid
Modified: 2013-12-18 19:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-04-05 01:49:41 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Junaid 2012-04-05 01:35:53 EDT
Description of problem:
After a graph switch from old graph to new graph, all the open fd's corresponding to the old graph must be opened freshly on the new graph. If the open fails, the error is not handled. Hence, any other operations are still allowed to proceed.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Open a file, then acquire a lock on the file
2. Execute a volume set command that will change the graph, like volume quota vol enable/disable
3. Acquire another lock on same fd from the same application on the same range. It will fail. Which means that the fd is in bad state because the owner of the lock that is being requested is this fd, hence the lock must have been granted.
4. Perform any other operation like read, write etc on the fd they will succeed.
5. Happens only when there is a graph switch.

Actual results:
File operations succeed.

Expected results:
File operations should return EBADFD error

Additional info:
Comment 1 Junaid 2012-04-05 01:49:41 EDT

*** This bug has been marked as a duplicate of bug 809919 ***

Note You need to log in before you can comment on or make changes to this bug.