[
https://issues.apache.org/jira/browse/HDFS-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13995353#comment-13995353
]
Colin Patrick McCabe commented on HDFS-6361:
--------------------------------------------
Some background would probably be helpful here. On Linux, user IDs (UIDs) are
32 bits. This convention goes all the way down into the kernel.
Typically they are treated as unsigned 32-bit numbers. So you'll find code
like this in {{bits/typesizes.h}}:
{code}
bits/typesizes.h:#define __UID_T_TYPE __U32_TYPE
{code}
Java, of course, does not have unsigned numbers. So we have to represent
numbers like 4294967295 as -1 in Java.
{code}
However, the effect of returning -2 from getUid and getGid for
+ * nfsnobody is yet to be understood
{code}
What is it that we have yet to understand? We better figure it out before we
commit this code.
{code}
+ private static Integer parseId(final String idStr) {
+ String tmpStr = idStr;
+ if (idStr.equals("4294967294")) {
+ tmpStr = "-2";
+ }
+ return Integer.valueOf(tmpStr);
+ }
{code}
I don't see a reason to special-case -2. We should treat all large integers >
0x7fffffff as negatives. If Java had unsigned numbers, we could just use an
unsigned 32 bit int... but it doesn't, so we can just use a signed int.
Basically, for the purposes of user IDs, -2 and 4294967294 are the same... at
least on Linux.
{code}
Another option to the patch I provided is to use something like a 64 bit
integer for ID, but the would be wide scope,
and I suspect it's going to be an overkill.
{code}
The Linux kernel itself doesn't use 64-bit numbers for UIDs. I'm not aware of
any kernels which do. So I don't see a benefit to this.
> TestIdUserGroup.testUserUpdateSetting failed due to out of range nfsnobody Id
> -----------------------------------------------------------------------------
>
> Key: HDFS-6361
> URL: https://issues.apache.org/jira/browse/HDFS-6361
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: nfs
> Affects Versions: 2.4.0
> Reporter: Yongjun Zhang
> Assignee: Yongjun Zhang
> Attachments: HDFS-6361.001.patch
>
>
> The following error happens pretty often:
> org.apache.hadoop.nfs.nfs3.TestIdUserGroup.testUserUpdateSetting
> Failing for the past 1 build (Since Unstable#61 )
> Took 0.1 sec.
> add description
> Error Message
> For input string: "4294967294"
> Stacktrace
> java.lang.NumberFormatException: For input string: "4294967294"
> at
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.lang.Integer.parseInt(Integer.java:495)
> at java.lang.Integer.valueOf(Integer.java:582)
> at
> org.apache.hadoop.nfs.nfs3.IdUserGroup.updateMapInternal(IdUserGroup.java:137)
> at
> org.apache.hadoop.nfs.nfs3.IdUserGroup.updateMaps(IdUserGroup.java:188)
> at org.apache.hadoop.nfs.nfs3.IdUserGroup.<init>(IdUserGroup.java:60)
> at
> org.apache.hadoop.nfs.nfs3.TestIdUserGroup.testUserUpdateSetting(TestIdUserGroup.java:71)
> Standard Output
> log4j:WARN No appenders could be found for logger
> (org.apache.hadoop.nfs.nfs3.IdUserGroup).
> log4j:WARN Please initialize the log4j system properly.
> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more
> info.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
