[
https://issues.apache.org/jira/browse/HADOOP-10527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13977617#comment-13977617
]
Colin Patrick McCabe commented on HADOOP-10527:
-----------------------------------------------
bq. Rearranged the code. Since the terminal condition of the loop has changed
(no more fixed limit on # of iterations), I moved realloc() back to after the
sys/lib calls. Compared to pre-HADOOP-10522, it uses single loop instead of
nested loop and return code/error handling was modified.
This looks good. Thanks.
bq. \[the comments about errno\] were removed in the previous patch. For a
second, I though I screwed up and posted an old patch again!
Oh, you're right. Sorry, I feel dumb now.
bq. Group lookups are different.The number of members in the group can vary a
lot. _SC_GETGR_R_SIZE_MAX is usually very big and allocating this much upfront
may not be ideal. So I set the initial buffer to be 8KB and allowed it to grow
up to 2MB.... What do you think about the new initial buffer size and the limit?
I was curious about this myself, so I ran the following program:
{code}
#include <stdio.h>
#include <unistd.h>
int main(void) {
fprintf(stderr, "%lld\n", (long long)sysconf(_SC_GETGR_R_SIZE_MAX));
return 0;
}
{code}
For me, it returned 1024. So I don't think {{_SC_GETGR_R_SIZE_MAX}} is usually
very big. Apparently the value of {{_SC_GETGR_R_SIZE_MAX}} is merely "an
initial suggested size" and not the actual maximum (as you might think by
reading its name). At least according to this:
http://tomlee.co/2012/10/problems-with-large-linux-unix-groups-and-getgrgid_r-getgrnam_r/
Anyway, I think your new starting size is good, because it will prevent
re-allocation in most cases. So I am +1 on the patch as-is. Thanks for
looking into this, Kihwal.
> Fix incorrect return code and allow more retries on EINTR
> ---------------------------------------------------------
>
> Key: HADOOP-10527
> URL: https://issues.apache.org/jira/browse/HADOOP-10527
> Project: Hadoop Common
> Issue Type: Bug
> Reporter: Kihwal Lee
> Assignee: Kihwal Lee
> Attachments: hadoop-10527.patch, hadoop-10527.patch,
> hadoop-10527.patch
>
>
> After HADOOP-10522, user/group look-up will only try up to 5 times on EINTR.
> More retries should be allowed just in case.
> Also, when a user/group lookup returns no entries, the wrapper methods are
> returning EIO, instead of ENOENT.
--
This message was sent by Atlassian JIRA
(v6.2#6252)