[
https://issues.apache.org/jira/browse/HDDS-1672?focusedWorklogId=258952&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-258952
]
ASF GitHub Bot logged work on HDDS-1672:
----------------------------------------
Author: ASF GitHub Bot
Created on: 12/Jun/19 17:45
Start Date: 12/Jun/19 17:45
Worklog Time Spent: 10m
Work Description: anuengineer commented on issue #949: HDDS-1672.
OzoneManager Lock change the volumeLock weight to 0
URL: https://github.com/apache/hadoop/pull/949#issuecomment-501382532
Unless I am completely out of my mind, this is a dangerous patch to commit.
We need to prove that taking user locks after volume locks is consistent across
all paths.
Right now, we think of user/volume/bucket/key as a logical hierarchy. Yes,
there are cases where you only have volume and you have to look back up the
path, and in that case, you might have to release a lock already taken. But
that is not an excuse to change the locking hierarchy if you want to do that,
You need to write down a locking conflict resolution table and prove that all
paths are consistent.
That is what we did when we first developed this locking hierarchy table,
Yes, it is a bit of work now, but will save us countless hours of work and pain
in the future.
Let us not commit this unless we have such a table. As I said, it might be
that this is correct, but this is a place where we have to be sure that this is
correct.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 258952)
Time Spent: 20m (was: 10m)
> OzoneManager Lock change the volumeLock weight to 0
> ---------------------------------------------------
>
> Key: HDDS-1672
> URL: https://issues.apache.org/jira/browse/HDDS-1672
> Project: Hadoop Distributed Data Store
> Issue Type: Bug
> Components: Ozone Manager
> Affects Versions: 0.4.0
> Reporter: Bharat Viswanadham
> Assignee: Bharat Viswanadham
> Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently after acquiring volume lock, we cannot acquire user lock.
> This is causing an issue in Volume request implementation,
> acquire/release/reacquire volume lock.
>
> Case of Delete Volume Request:
> # Acquire volume lock.
> # Get Volume Info from DB
> # Release Volume lock. (We are releasing the lock, because while acquiring
> volume lock, we cannot acquire user lock0
> # Get owner from volume Info read from DB
> # Acquire owner lock
> # Acquire volume lock
> # Do delete logic
> # release volume lock
> # release user lock
>
> We can avoid this acquire/release/reacquire lock issue by making volume lock
> as low weight.
>
> In this way, the above deleteVolume request will change as below
> # Acquire volume lock
> # Get Volume Info from DB
> # Get owner from volume Info read from DB
> # Acquire owner lock
> # Do delete logic
> # release owner lock
> # release volume lock.
> Same issue is seen with SetOwner for Volume request also.
> During HDDS-1620 [~arp] brought up this issue.
> I am proposing the above solution to solve this issue. Any other
> idea/suggestions are welcome.
> This also resolves a bug in setOwner for Volume request.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
