@Ranjit masetty , No, you won't. Even if you have a record for a.txt in FSImage it will check change log to ensure it was not deleted or renamed. Since edit log shows you renamed a.txt NameNode will return with no file. Parsing edit log is a very fast process. ... View more

I cannot get your question. Why do you think you need to update the group file? ... View more

@suresh krish What is your OS? Seems like you haven't created database for you realm. If you have Debian/Ubuntu try krb5_newrealm command, else try kdb5_util create -s -r YOUR_REALM ... View more

@satya gaurav, If you feel you got the answer for your question please accept one of the answers. ... View more

Yes, it will use RAM since it is the fastest way to reach the required data. That is why Apache recommends to use lot of memory on NN. ... View more

"as per your explanation edits log and fsimage store changes only from the last checkpoint" No. Your HDFS state is stored in FSImage. All the changes (rename, delete, permission change) to last checkpoint will be stored in edit log. To avoid that the edit log to be too large sometimes the SN applies the changes from edit log in FSImage. That means FSImage stores your whole HDFS state not only from the last checkpoint. With other words, the checkpoint is actually the FSImage. This whole process is needed because it is hard to write FSImage it is easier to write the changes into edit log, but edit log could be too large so merge is needed in certain period. Example: You have a file a.txt and you rename to b.txt. After you rename b.txt to c.txt FSImage shows you have a.txt and in edit log it stores you had two renames (a -> b, b -> c) After SN merges FSImage and edit log: Edit log will be empty and FSImage will show you have c.txt. There will be no any record for a.txt. Does it answer you question? ... View more

@satya gaurav Welcome at Hortonworks Community. I feel some misunderstanding here. FSimage is a point-in-time snapshot of HDFS's namespace. Edit log records every changes from the last snapshot. The last snapshot is actually stored in FSImage. So edit log records the changes that was taken on the file system and (to avoid the problem you came up with) in a certain period (based on your cluster settings) Standby Node or SN will merge edit log to FSImage and returns with a new FSImage. That means HDFS does not need to store all the changes from the last 10 years. It stores the changes only from the last checkpoint. The size of FSImage does not depend on time the NN running from. It depends on the size of HDFS namespace (number of files, users, etc). You can set the snapshot period with dfs.namenode.checkpoint.check.period Another option is to limit the number of stored transactions. Use dfs.namenode.checkpoint.txns Hope it helps. If it still not clear enough feel free to ask. ... View more

Hi, ticket_lifetime: Every ticket has a life time which is usually less than a day. After this period the ticket considered as expired and you are no longer be able to use your ticket. You have to obtain another one. The renewable tickets have another property: renew_lifetime: E.g. if your ticket has 7d renew_lifetime you can renew your ticket (with kinit -R) for 7d without typing you password again and the expiration date will be current date + ticket_lifetime. It is important that you cannot renew an expired ticket. So you have 24h as ticket_lifetime and 7d as renew_lifetime. If you acquire your ticket on Monday 00:00 you can use your ticket until Tuesday 00:00. Before it expires (before Tuesday) you can renew it with kinit -R (and you have to renew it every day). With other words renew_lifetime is the maximum lifetime of a ticket. As I mentioned earlier once a ticket expired (by its ticket_lifetime) you cannot renew it. ... View more