FSEditLogLoader.applyEditLogOp

When namenode start, it load namespace information from fs image, and replay information from edit log.

FSEditLogLoader. applyEditLogOp

 private long applyEditLogOp(FSEditLogOp op, FSDirectory fsDir,
      StartupOption startOpt, int logVersion, long lastInodeId) throws IOException {
    long inodeId = INodeId.GRANDFATHER_INODE_ID;
    if (LOG.isTraceEnabled()) {
      LOG.trace("replaying edit log: " + op);
    }
    final boolean toAddRetryCache = fsNamesys.hasRetryCache() && op.hasRpcIds();

    switch (op.opCode) {
    // omit some case ...
    case OP_MKDIR: {
      MkdirOp mkdirOp = (MkdirOp)op;
      inodeId = getAndUpdateLastInodeId(mkdirOp.inodeId, logVersion,
          lastInodeId);
      FSDirMkdirOp.mkdirForEditLog(fsDir, inodeId,
          renameReservedPathsOnUpgrade(mkdirOp.path, logVersion),
          mkdirOp.permissions, mkdirOp.aclEntries, mkdirOp.timestamp);
      break;
    }

    default:
      throw new IOException("Invalid operation read " + op.opCode);
    }
    return inodeId;
  }

OP_MKDIR example from edit log transformed using ”hdfs oev ”

 <RECORD>
    <OPCODE>OP_MKDIR</OPCODE>
    <DATA>
      <TXID>3</TXID>
      <LENGTH>0</LENGTH>
      <INODEID>16387</INODEID>
      <PATH>/user/houzhizhen</PATH>
      <TIMESTAMP>1515482300917</TIMESTAMP>
      <PERMISSION_STATUS>
        <USERNAME>houzhizhen</USERNAME>
        <GROUPNAME>supergroup</GROUPNAME>
        <MODE>493</MODE>
      </PERMISSION_STATUS>
    </DATA>
  </RECORD>

So, despite the inode store user id and group id, it stores user name and group name in the edit file. The user id and group id may not the same during different namenode. The namenode does not expose the user id and group id to the outside. It exposes only user name and group name, so the difference of user id and group id from the different namenode startup will cause no problem.