captainzmc commented on a change in pull request #1489: URL: https://github.com/apache/ozone/pull/1489#discussion_r513216585
########## File path: hadoop-ozone/ozone-manager/src/main/java/org/apache/hadoop/ozone/om/request/key/OMKeyRequest.java ########## @@ -597,27 +596,40 @@ protected boolean checkDirectoryAlreadyExists(String volumeName, } /** - * Return volume info for the specified volume. If the volume does not - * exist, returns {@code null}. + * Return volume info that updated usageBytes for the specified volume. * @param omMetadataManager * @param volume + * @param updateUsage * @return OmVolumeArgs * @throws IOException */ - protected OmVolumeArgs getVolumeInfo(OMMetadataManager omMetadataManager, - String volume) { - - OmVolumeArgs volumeArgs = null; - - CacheValue<OmVolumeArgs> value = - omMetadataManager.getVolumeTable().getCacheValue( - new CacheKey<>(omMetadataManager.getVolumeKey(volume))); - - if (value != null) { - volumeArgs = value.getCacheValue(); - } + protected static synchronized OmVolumeArgs syncUpdateUsage( + OMMetadataManager omMetadataManager, String volume, long updateUsage) { + OmVolumeArgs volumeArgs = omMetadataManager.getVolumeTable().getCacheValue( + new CacheKey<>(omMetadataManager.getVolumeKey(volume))) + .getCacheValue(); + volumeArgs.getUsedBytes().add(updateUsage); + return volumeArgs.copyObject(); + } - return volumeArgs; + /** + * Return volume info that updated usageBytes for the specified volume. And + * check Volume usageBytes quota. + * @param omMetadataManager + * @param volume + * @param updateUsage + * @return OmVolumeArgs + * @throws IOException + */ + protected static synchronized OmVolumeArgs syncCheckAndUpdateUsage( Review comment: > I have not understood one part, how without volume lock this will help here. > > Because other threads can be updating volumeArgs when this update is happening/ other threads read omVolumeArgs. Thank for @bharatviswa504's feedback. This is a possible case. Can lead to update usageBytes inaccurate. Suppose that ThreadA update VolumeArgs using OMVolumeSetOwnerRequest, it gets VolumeArgs from DB if usageBytes is 1000 at this point. When ThreadB writes the new key using OMKeyCreateRequest, he changes usageBytes to 1100. There is no Volume lock at this point, so ThreadB may finish executing first and ThreadA last. The Final usageBytes for VolumeArgs would be 1000. This should be a problem. Maybe we still can't avoid using Volume lock. hi @linyiqun Any suggestions here? ---------------------------------------------------------------- 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: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: ozone-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: ozone-issues-h...@hadoop.apache.org