-
Notifications
You must be signed in to change notification settings - Fork 8.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HDFS-16534. Split FsDatasetImpl from block pool locks to volume grain locks. #4141
Conversation
💔 -1 overall
This message was automatically generated. |
8e2e66f
to
315565e
Compare
🎊 +1 overall
This message was automatically generated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems that there are different method which is not improve the lock level from BlockPool level to Volume level, such as onCompleteLazyPersist, evictBlocks
and others, any consideration?
...-hdfs/src/main/java/org/apache/hadoop/hdfs/server/datanode/fsdataset/impl/FsDatasetImpl.java
Outdated
Show resolved
Hide resolved
@@ -629,6 +634,9 @@ public void removeVolumes( | |||
synchronized (this) { | |||
for (String storageUuid : storageToRemove) { | |||
storageMap.remove(storageUuid); | |||
for (String bp : volumeMap.getBlockPoolList()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we need to synchronized this segment? IMO, lock remove is thread safe here, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It may add lot of locks. All method related add/remove locks is get synchronized first.
...-hdfs/src/main/java/org/apache/hadoop/hdfs/server/datanode/fsdataset/impl/FsDatasetImpl.java
Show resolved
Hide resolved
...-hdfs/src/main/java/org/apache/hadoop/hdfs/server/datanode/fsdataset/impl/FsDatasetImpl.java
Show resolved
Hide resolved
...-hdfs/src/main/java/org/apache/hadoop/hdfs/server/datanode/fsdataset/impl/FsDatasetImpl.java
Show resolved
Hide resolved
.getNumBytes()); | ||
FsVolumeImpl v = (FsVolumeImpl) ref.getVolume(); | ||
ReplicaInPipeline newReplicaInfo; | ||
FsVolumeReference ref = volumes.getNextVolume(storageType, storageId, b |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if this is thread safe without any ReadWriteLock
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
volumes. getNextVolume() is thread safe, and no need protected by dataset lock.
Please fix checkstyle as Yetus suggest /results-checkstyle-hadoop-hdfs-project_hadoop-hdfs.txt |
315565e
to
6f4ffd6
Compare
1、some method is not good change to volume lock, and if split to volume lock it have to get locks and release locks sequence(like acquire lock1, lock2, lock3, release lock 3 lock2 lock1).So just acquire block pool lock is enough. |
🎊 +1 overall
This message was automatically generated. |
LGTM +1 from my side. I would like to check into trunk if no furthermore feedback while 5 work days later.
I would like to clarify this explanation. This improvement only change part of methods from block pool level lock to volume level lock rather all. Because, Thanks @MingXiangLi for your works. |
… locks. (#4141) Contributed by limingxiang. Signed-off-by: He Xiaoqiao <hexiaoqiao@apache.org>
Committed to trunk. Thanks @MingXiangLi for your contributions. |
… locks. (apache#4141) Contributed by limingxiang. Signed-off-by: He Xiaoqiao <hexiaoqiao@apache.org>
https://issues.apache.org/jira/browse/HDFS-15382 have split lock to block pool grain and do some prepare.This pr is the last part of volume lock.