[
https://issues.apache.org/jira/browse/HDFS-17800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18077406#comment-18077406
]
ASF GitHub Bot commented on HDFS-17800:
---------------------------------------
Kimahriman commented on PR #7754:
URL: https://github.com/apache/hadoop/pull/7754#issuecomment-4355030070
> Thanks @Kimahriman for your contribution.
>
> Make sense to me.
>
> Maybe you can split this MR to two MRs:
>
> 1. The first MR correct EC checks for ObserverRead
> 2. The second MR correct EC checks for safeMode, since I saw that some
other methods missed safemode check, such as: getFileInfo. Maybe you can sort
out all related cases and fix them together.
The two cases are kind of linked, as the bug I am fixing is when an observer
node is in safemode. It seems like there's maybe some inconsistencies but I'm
not sure what the "correct" behavior is. Seems like there are four methods and
two cases where this matters:
- `getBatchedListing(..., needLocation=true)`/`getBlockLocations`: Only
returns a valid response in safemode if there are enough replicas to satisfy
the request. This could be from an active or observer node.
- `getFileInfo(..., needLocation=true)`/`getListing(...,
needLocation=true)`: Only returns a valid response from observer an observer if
there are enough replicas to satisfy the request, whether in safemode or not.
If an active is in safemode, will always return the response because
I guess the downside of the second bullet is there may be an observer node
that has more correct/up to date info than an active in safemode, so it would
be better to return an error in that case instead of returning the best thing
it can
> Observer node can return insufficient blocks for erasure coded files
> --------------------------------------------------------------------
>
> Key: HDFS-17800
> URL: https://issues.apache.org/jira/browse/HDFS-17800
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: hdfs
> Affects Versions: 3.4.1
> Reporter: Adam Binford
> Priority: Major
> Labels: pull-request-available
>
> Similar to https://issues.apache.org/jira/browse/HDFS-13924,
> https://issues.apache.org/jira/browse/HDFS-16732, and
> https://issues.apache.org/jira/browse/HDFS-17768, except for erasure coded
> files. A single block may not be enough to fulfill an erasure coded read, as
> you need at least the number of data shards of blocks to read an erasure
> coded file. The checks need to be updated to factor in erasure coded files.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]