[ 
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)

Reply via email to