Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 5 Sep 2017 20:52:00 +0000 (UTC)
From: "Chen Liang (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <JIRA.13080960.1497914774000.32250.1504644720341@Atlassian.JIRA>
In-Reply-To: <JIRA.13080960.1497914774000@Atlassian.JIRA>
References: <JIRA.13080960.1497914774000@Atlassian.JIRA> <JIRA.13080960.1497914774014@jira-lw-us.apache.org>
Subject: [jira] [Updated] (HDFS-12000) Ozone: Container : Add key versioning
 support-1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 05 Sep 2017 20:52:09 -0000


     [ https://issues.apache.org/jira/browse/HDFS-12000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chen Liang updated HDFS-12000:
------------------------------
    Attachment: HDFS-12000-HDFS-7240.004.patch

Thanks [~xyao] for the comments! Addressed all your comments in v004 patch except the following:

bq. Line 281: Please file followup JIRAs for TODO
bq. Line 81: NIT: getLatestVersionList -> getLatestLocations, can we modify this function to take version as parameter so that this can be reused later when versions other than latest are fully supported.

Will definitely do. Since it will actually involve some more code of retrieving the version, new APIs of requesting/returning specific version etc, I was planning for having a separate JIRA about getting specific version of block. there will be a couple of more JIRAs for versioning to work fully, reading a specific version will be one of the next JIRAs for sure.

bq. Since we only update the latestVersion at commit time, there could be multiple clients that allocate blocks before the first commit is done. Once the first commit is done, all the allocate will be invalid to commit due to the logic between line 109-115.
This is exactly what I was trying to do in this part. When multiple clients try to write the data, only one will succeed, the others will get exception, and maybe retry later. This works just same purpose as a write lock, such that when multiple writes are racing, we will never end up having a version that is an uncertain mix of multiple different writes.

In addition, since delete key work is in-progress, I will need to look closer to see if there is anything conflicting between delete key and this versioning code. Submitting v004 patch anyway for now mainly for early review purpose.

> Ozone: Container : Add key versioning support-1
> -----------------------------------------------
>
>                 Key: HDFS-12000
>                 URL: https://issues.apache.org/jira/browse/HDFS-12000
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>          Components: ozone
>    Affects Versions: HDFS-7240
>            Reporter: Anu Engineer
>            Assignee: Chen Liang
>         Attachments: HDFS-12000-HDFS-7240.001.patch, HDFS-12000-HDFS-7240.002.patch, HDFS-12000-HDFS-7240.003.patch, HDFS-12000-HDFS-7240.004.patch, OzoneVersion.001.pdf
>
>
> The rest interface of ozone supports versioning of keys. This support comes from the containers and how chunks are managed to support this feature. This JIRA tracks that feature. Will post a detailed design doc so that we can talk about this feature.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org