bharatviswa504 commented on a change in pull request #1679: URL: https://github.com/apache/ozone/pull/1679#discussion_r541128115
########## File path: hadoop-ozone/ozone-manager/src/main/java/org/apache/hadoop/ozone/om/request/key/OMAllocateBlockRequestV1.java ########## @@ -0,0 +1,91 @@ +/** + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * <p> + * http://www.apache.org/licenses/LICENSE-2.0 + * <p> + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +package org.apache.hadoop.ozone.om.request.key; + +import org.apache.hadoop.ozone.om.OMMetadataManager; +import org.apache.hadoop.ozone.om.OzoneManager; +import org.apache.hadoop.ozone.om.helpers.OmBucketInfo; +import org.apache.hadoop.ozone.om.helpers.OmKeyInfo; +import org.apache.hadoop.ozone.om.helpers.OmVolumeArgs; +import org.apache.hadoop.ozone.om.helpers.OzoneFSUtils; +import org.apache.hadoop.ozone.om.request.file.OMFileRequest; +import org.apache.hadoop.ozone.om.response.OMClientResponse; +import org.apache.hadoop.ozone.om.response.key.OMAllocateBlockResponseV1; +import org.apache.hadoop.ozone.protocol.proto.OzoneManagerProtocolProtos.OMRequest; +import org.apache.hadoop.ozone.protocol.proto.OzoneManagerProtocolProtos.OMResponse; +import org.jetbrains.annotations.NotNull; +import org.slf4j.Logger; +import org.slf4j.LoggerFactory; + +import java.io.IOException; +import java.nio.file.Path; +import java.nio.file.Paths; +import java.util.Iterator; + +/** + * Handles allocate block request layout version V1. + */ +public class OMAllocateBlockRequestV1 extends OMAllocateBlockRequest { + + private static final Logger LOG = + LoggerFactory.getLogger(OMAllocateBlockRequestV1.class); + + public OMAllocateBlockRequestV1(OMRequest omRequest) { + super(omRequest); + } + + protected OmKeyInfo getOpenKeyInfo(OMMetadataManager omMetadataManager, + String openKeyName, String keyName) throws IOException { + String fileName = OzoneFSUtils.getFileName(keyName); + return OMFileRequest.getOmKeyInfoFromFileTable(true, + omMetadataManager, openKeyName, fileName); + } + + protected String getOpenKeyName(String volumeName, String bucketName, + String keyName, long clientID, OzoneManager ozoneManager) + throws IOException { + OMMetadataManager omMetadataManager = ozoneManager.getMetadataManager(); + String bucketKey = omMetadataManager.getBucketKey(volumeName, bucketName); + OmBucketInfo omBucketInfo = + omMetadataManager.getBucketTable().get(bucketKey); + long bucketId = omBucketInfo.getObjectID(); + String fileName = OzoneFSUtils.getFileName(keyName); + Iterator<Path> pathComponents = Paths.get(keyName).iterator(); Review comment: Yes, I agree the ideal thing should be doing this under bucket lock whole operation. But that will have performance impact, as previously allocate block was done with out lock. Previous code has a similar issue, even then during key commit, it might not be found out, and also before we don't have atomic delete, so nothing can be really guaranteed. In new approach deletes are atomic, and when delete only parent dir is removed, and childs are deleted asynchronously. With new approach, this will be figured out during key commit (As we iterate the entire path again). But it will have impact on performance, and client may write some additional block data even when parent dir's are removed. (This is the only a problem for fs semantics, not object-store semantics). This will be eventually figured out during the next allocateblock, keycommit. So, here we need to make a choice, do we want to detect during allocate block or during commit Key. cc @mukul1987 @arp7 for comments Reading code more, only bucket lock is not there when key check, so we should be okay I believe holding lock during traversal? ( I think this is changed during quota change, previously in allocate block we are not holding lock ---------------------------------------------------------------- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
