Does tunning requires re-formatting Namenode ?

[praveenesh kumar <pr...@gmail.com>]

Hey Guys,

Do I need to format the namenode again if I am changing some HDFS
configurations like blocksize, checksum, compression codec etc or is there
any other way to enforce these new changes in the present cluster setup ?

Thanks,
Praveenesh

Re: Does tunning requires re-formatting Namenode ?

[Harsh J <ha...@cloudera.com>]

Praveenesh,

*Never* reformat your namenode unless you want to blow all your files away and start afresh. No configuration change will ever demand that you reformat your NameNode.

* Block size is per-file, so you can change this config to affect the default of all new files, but to change older files' block sizes you'd have to recreate them with newer block size and replace them.
* Checksum -- Which particular config are you talking about here?
* Compression - No issues arise out of extending codecs. HDFS has no concept of compression thus far, so doesn't affect it at all. It user processes (including MR) that are affected by these configs.

Presently, some configs may be enforced with <final>true</final> flags, but it all depends on how your clients load their configurations.

On 09-Jan-2012, at 10:56 AM, praveenesh kumar wrote:

> Hey Guys,
> 
> Do I need to format the namenode again if I am changing some HDFS
> configurations like blocksize, checksum, compression codec etc or is there
> any other way to enforce these new changes in the present cluster setup ?
> 
> Thanks,
> Praveenesh

Re: Does tunning requires re-formatting Namenode ?

[Srinivas Surasani <va...@gmail.com>]

Hi Praveenesh,

You just need to restart the hadoop services. Reformatting the namenode
causes the lose of metadata and there by loss of data residing in datanodes.

Regards,
Srinivas,
Cloudwick Technologies.

On Mon, Jan 9, 2012 at 12:26 AM, praveenesh kumar <pr...@gmail.com>wrote:

> Hey Guys,
>
> Do I need to format the namenode again if I am changing some HDFS
> configurations like blocksize, checksum, compression codec etc or is there
> any other way to enforce these new changes in the present cluster setup ?
>
> Thanks,
> Praveenesh
>