[ 
https://issues.apache.org/jira/browse/HADOOP-20066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18138463#comment-18138463
 ] 

ASF GitHub Bot commented on HADOOP-20066:
-----------------------------------------

LuciferYang opened a new pull request, #8930:
URL: https://github.com/apache/hadoop/pull/8930

   ### Description of PR
   
   JIRA: https://issues.apache.org/jira/browse/HADOOP-20066
   
   For an unknown size, `AllocatorPerContext#getLocalPathForWrite` picks a 
directory at random, weighted by free space, and subtracts a directory's space 
from `totalAvailable` when `createPath()` fails for it. A directory with no 
usable space still counts toward `numDirs`, so after every directory with space 
has failed, `totalAvailable` is 0 while the loop still runs, and `(r.nextLong() 
>>> 1) % totalAvailable` throws `ArithmeticException: / by zero` instead of the 
`DiskErrorException` that lists the directories. One full disk plus a disk 
remounted read-only is enough, and since the context is only rebuilt when the 
configuration changes, every such allocation in that JVM fails the same way.
   
   This patch adds `totalAvailable > 0` to the loop condition, so the existing 
`DiskErrorException` is thrown. HADOOP-9079 proposed the same change in 2012, 
but it was not committed.
   
   ### How was this patch tested?
   
   Added `TestLocalDirAllocator#testGetLocalPathForWriteWhenAllDirsFailCreate` 
(parameterized like its neighbours): one buffer directory is removed and cannot 
be recreated, the other is made read-only, and `getLocalPathForWrite` must 
throw `DiskErrorException` naming both. Without the fix it throws 
`ArithmeticException`.
   
   ### For code changes:
   
   - [x] Does the title of this PR start with the corresponding JIRA issue id 
(e.g. 'HADOOP-17799. Your PR title ...')?
   - [ ] Object storage: Have the integration tests been executed and the 
endpoint declared according to the connector-specific documentation?
   - [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?
   - [ ] If applicable, have you updated the `LICENSE`, `LICENSE-binary`, 
`NOTICE-binary` files?
   
   ### AI Tooling
   
   - [x] The PR includes the phrase "Contains content generated by Claude Opus".
   - [x] My use of AI contributions follows the ASF legal policy 
https://www.apache.org/legal/generative-tooling.html
   
   Contains content generated by Claude Opus.
   




> LocalDirAllocator throws ArithmeticException instead of DiskErrorException 
> when every directory with free space fails the write check
> -------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: HADOOP-20066
>                 URL: https://issues.apache.org/jira/browse/HADOOP-20066
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: fs
>            Reporter: Yang Jie
>            Priority: Minor
>
> When the size is unknown, AllocatorPerContext#getLocalPathForWrite picks a 
> directory at random, weighted by its free space. If the chosen directory 
> fails createPath(), its space is subtracted from {{totalAvailable}} and it 
> counts as searched. A directory with no usable space still counts toward 
> {{numDirs}}, so after every directory with space has failed, 
> {{totalAvailable}} is 0 while {{numDirsSearched < numDirs}} still holds, and 
> the next {{(r.nextLong() >>> 1) % totalAvailable}} throws 
> "ArithmeticException: / by zero".
> This needs two or more directories, at least one with no usable space, and 
> every directory with space failing createPath(), for example a disk remounted 
> read-only. The allocator only rebuilds its context when the configuration 
> changes, so in a task or client JVM every such allocation fails from then on. 
> Callers expect a DiskErrorException, which is an IOException; they get an 
> unchecked exception instead, without the message that lists the directories.
> The fix stops the loop once no space is left, so the existing 
> DiskErrorException is thrown. HADOOP-9079 reported this case in 2012 with the 
> same change, but it was never committed.



--
This message was sent by Atlassian Jira
(v10.3.26#10030026)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to