[
https://issues.apache.org/jira/browse/HDFS-15532?focusedWorklogId=482770&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-482770
]
ASF GitHub Bot logged work on HDFS-15532:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 12/Sep/20 20:19
Start Date: 12/Sep/20 20:19
Worklog Time Spent: 10m
Work Description: ayushtkn commented on a change in pull request #2298:
URL: https://github.com/apache/hadoop/pull/2298#discussion_r487368520
##########
File path:
hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/viewfs/ViewFileSystem.java
##########
@@ -1263,6 +1263,26 @@ public boolean delete(final Path f)
public BlockLocation[] getFileBlockLocations(final FileStatus fs,
final long start, final long len) throws
FileNotFoundException, IOException {
+
+ // When application calls listFiles on internalDir, it would return
+ // RemoteIterator from InternalDirOfViewFs. If there is a fallBack, there
+ // is a chance of files exists under that internalDir in fallback.
+ // Iterator#next will call getFileBlockLocations with that files. So, we
+ // should return getFileBlockLocations on fallback. See HDFS-15532.
+ if (fs.getPath() != InodeTree.SlashPath && this.fsState
+ .getRootFallbackLink() != null) {
+ FileSystem linkedFallbackFs =
+ this.fsState.getRootFallbackLink().getTargetFileSystem();
+ Path parent = Path.getPathWithoutSchemeAndAuthority(
+ new Path(theInternalDir.fullPath));
+ String leafChild = (InodeTree.SlashPath.equals(fs.getPath())) ?
+ InodeTree.SlashPath.toString() :
+ fs.getPath().getName();
Review comment:
`(InodeTree.SlashPath.equals(fs.getPath()))`
In which case this would be true? Provided there is a check in the if
condition
----------------------------------------------------------------
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:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 482770)
Time Spent: 1h 40m (was: 1.5h)
> listFiles on root/InternalDir will fail if fallback root has file
> -----------------------------------------------------------------
>
> Key: HDFS-15532
> URL: https://issues.apache.org/jira/browse/HDFS-15532
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Affects Versions: 3.4.0
> Reporter: Uma Maheswara Rao G
> Assignee: Uma Maheswara Rao G
> Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> listFiles implementation gets the RemoteIterator created in
> InternalViewFSDirFs as the root is an InternalViewFSDir.
> If there is a fallback and a file exist at root level, it would have
> collected when collecting locatedStatuses.
> When its iterating over to that fallbacks file from RemoteIterator (which
> was returned from InternalViewFSDirFs ), iterator's next will will call
> getFileBlockLocations if it's a file.
> {code:java}
> @Override
> public LocatedFileStatus next() throws IOException {
> System.out.println(this);
> if (!hasNext()) {
> throw new NoSuchElementException("No more entries in " + f);
> }
> FileStatus result = stats[i++];
> // for files, use getBlockLocations(FileStatus, int, int) to avoid
> // calling getFileStatus(Path) to load the FileStatus again
> BlockLocation[] locs = result.isFile() ?
> getFileBlockLocations(result, 0, result.getLen()) :
> null;
> return new LocatedFileStatus(result, locs);
> }{code}
>
> this getFileBlockLocations will be made on InternalViewFSDirFs, as that
> Iterator created originally from that fs.
> InternalViewFSDirFs#getFileBlockLocations does not handle fallback cases.
> It's always expecting "/", this means it always assuming the dir.
> But with the fallback and returning Iterator from InternalViewFSDirFs, will
> create problems.
> Probably we need to handle fallback case in getFileBlockLocations as well.(
> Fallback only should be the reason for call coming to InternalViewFSDirFs
> with other than "/")
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
