[
https://issues.apache.org/jira/browse/HDFS-5546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14034630#comment-14034630
]
Daryn Sharp commented on HDFS-5546:
-----------------------------------
This is not an acceptable patch. It's not ok to swallow the FNF and return a
success exit code.
Maybe I'm misunderstanding the description. Is this jira only trying to
address a tiny race if the path existed when the command started, but
disappeared before being listed? If yes, then FNF is exactly the correct
behavior. After that, the stats you see being checked in the code are supposed
to be from listStatus.
If you are trying to make ls always forge ahead when it gets FNF while in a
subdir, that has some peril associated with it. What if the item being listed
isn't what was deleted? What if an ancestor directory was deleted? Should ls
keep pounding on the NN to list every directory it thinks should be there? And
then as it ascends back up the tree should keep trying to list other siblings
it thinks should be there?
> race condition crashes "hadoop ls -R" when directories are moved/removed
> ------------------------------------------------------------------------
>
> Key: HDFS-5546
> URL: https://issues.apache.org/jira/browse/HDFS-5546
> Project: Hadoop HDFS
> Issue Type: Bug
> Affects Versions: 2.2.0
> Reporter: Colin Patrick McCabe
> Assignee: Lei (Eddy) Xu
> Priority: Minor
> Fix For: 3.0.0
>
> Attachments: HDFS-5546.1.patch, HDFS-5546.2.000.patch,
> HDFS-5546.2.001.patch, HDFS-5546.2.002.patch
>
>
> This seems to be a rare race condition where we have a sequence of events
> like this:
> 1. org.apache.hadoop.shell.Ls calls DFS#getFileStatus on directory D.
> 2. someone deletes or moves directory D
> 3. org.apache.hadoop.shell.Ls calls PathData#getDirectoryContents(D), which
> calls DFS#listStatus(D). This throws FileNotFoundException.
> 4. ls command terminates with FNF
--
This message was sent by Atlassian JIRA
(v6.2#6252)
