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.
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. Any suggestions here?
@linyiqun
----------------------------------------------------------------
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
