You are viewing a plain text version of this content. The canonical link for it is here.
Posted to hdfs-issues@hadoop.apache.org by "ZanderXu (Jira)" <ji...@apache.org> on 2024/05/10 10:40:00 UTC
[jira] [Updated] (HDFS-17505) [FGL] Solutions for StoragePolicy
[ https://issues.apache.org/jira/browse/HDFS-17505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
ZanderXu updated HDFS-17505:
----------------------------
Description:
StoragePolicy may be set on an ancestor path and used by some children files.
This storage policy are used by many operations, but there are two special operations:
* ChooseExcessRedundancies
* BlockReconstructionWork
ChooseExcessRedundancies is used to process some excess redundancy replicas. BR and IBR may need to process some excess redundancy replicas.
It means that :
* BR and IBR needs to hold not only the global BM write lock but also the global FS write lock in phase 2.
* BR and IBR needs to hold not only the write lock of last iNode file but also the full directory tree locks in phase 3.
It will results in a low performance.
In order to fix it, there are some solutions.
Solution 1:
* Using a separate thread to process these excess redundancy blocks periodically, such as the Redundancy monitor.
* This thread can hold the full directory tree locks to process these blocks in phase 3.
Solution 2:(preferred)
* Try to set the storage policy to each iNodeFile, so that BM related operations can only involve the iNodeFile to which the processing block belongs.
* It's solution will not cost more memory.
* The storage policy can be set synchronously to all children iNodeFiles. setStoragePolicy, unsetStoragePolicy and rename require this operation.
was:
StoragePolicy may be set on an ancestor path and used by some children files.
This storage policy are used by many operations, but there are two special operations:
* ChooseExcessRedundancies
* BlockReconstructionWork
ChooseExcessRedundancies is used to process some excess redundancy replicas. BR and IBR may need to process some excess redundancy replicas.
It means that :
* BR and IBR needs to hold not only the global BM write lock but also the global FS write lock in phase 2.
* BR and IBR needs to hold not only the write lock of last iNode file but also the full directory tree locks in phase 3.
It will results in a low performance.
In order to fix it, there are some solutions.
Solution 1: (preferred)
* Using a separate thread to process these excess redundancy blocks periodically, such as the Redundancy monitor.
* This thread can hold the full directory tree locks to process these blocks in phase 3.
Solution 2:
* Try to set the storage policy to each iNodeFile, so that BM related operations can only involve the iNodeFile to which the processing block belongs.
* It's solution will not cost more memory.
* The storage policy can be set asynchronously to all children iNodeFiles. setStoragePolicy, unsetStoragePolicy and rename require this operation.
> [FGL] Solutions for StoragePolicy
> ---------------------------------
>
> Key: HDFS-17505
> URL: https://issues.apache.org/jira/browse/HDFS-17505
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Reporter: ZanderXu
> Assignee: ZanderXu
> Priority: Major
>
> StoragePolicy may be set on an ancestor path and used by some children files.
>
> This storage policy are used by many operations, but there are two special operations:
> * ChooseExcessRedundancies
> * BlockReconstructionWork
>
> ChooseExcessRedundancies is used to process some excess redundancy replicas. BR and IBR may need to process some excess redundancy replicas.
> It means that :
> * BR and IBR needs to hold not only the global BM write lock but also the global FS write lock in phase 2.
> * BR and IBR needs to hold not only the write lock of last iNode file but also the full directory tree locks in phase 3.
>
> It will results in a low performance.
>
> In order to fix it, there are some solutions.
> Solution 1:
> * Using a separate thread to process these excess redundancy blocks periodically, such as the Redundancy monitor.
> * This thread can hold the full directory tree locks to process these blocks in phase 3.
>
> Solution 2:(preferred)
> * Try to set the storage policy to each iNodeFile, so that BM related operations can only involve the iNodeFile to which the processing block belongs.
> * It's solution will not cost more memory.
> * The storage policy can be set synchronously to all children iNodeFiles. setStoragePolicy, unsetStoragePolicy and rename require this operation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org