Bug 810079 - Handle failures of open fd migration from old graph to new graph
Summary: Handle failures of open fd migration from old graph to new graph
Keywords:
Status: CLOSED DUPLICATE of bug 809919
Alias: None
Product: GlusterFS
Classification: Community
Component: core
Version: mainline
Hardware: Unspecified
OS: All
unspecified
medium
Target Milestone: ---
Assignee: Amar Tumballi
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-04-05 05:35 UTC by Junaid
Modified: 2013-12-19 00:07 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-04-05 05:49:41 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)

Description Junaid 2012-04-05 05:35:53 UTC
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):
release-3.3

How reproducible:
Always

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 05:49:41 UTC

*** 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.