tune2fs -E hash_alg=half_md4: safe for existing filesystems?

[Bryn M. Reeves]

On 01/09/2013 06:18 PM, Bill Davidsen wrote:
> I would try this on something you can afford to lose... I just don't see
> any more info on this than you did before asking. I am curious, since I

Changing hash_alg on an existing file system sets the default hash 
algorithm for newly created directories. It won't affect any existing 
directory inodes that are already present (even if you remove all the 
files within them - you need to remove and re-create the directory 
itself to switch algorithm).

File systems with mixed hash algorithms probably see a lot less testing 
than either one or the other but both options have been around for quite 
a while now.

You can test this easily enough on loopback devices if needed and 
there's no real storage available and use debugfs to inspect the hash 
used for a particular directory, e.g.:

debugfs> htree foo
Root node dump:
	 Reserved zero: 0
	 Hash Version: 2
	 Info length: 8
	 Indirect levels: 0
	 Flags: 0
Number of entries (count): 2
Number of entries (limit): 124
Entry #0: Hash 0x00000000, block 1
Entry #1: Hash 0x896bc308, block 2
[...]

debugfs> htree bar
Root node dump:
	 Reserved zero: 0
	 Hash Version: 1
	 Info length: 8
	 Indirect levels: 0
	 Flags: 0
Number of entries (count): 2
Number of entries (limit): 124
Entry #0: Hash 0x00000000, block 1
Entry #1: Hash 0x7aa4fee4, block 2
[...]

The hash versions are as follows:

#define EXT2_HASH_LEGACY                0
#define EXT2_HASH_HALF_MD4              1
#define EXT2_HASH_TEA                   2

It's probably somewhat more risky than re-making the file system with 
the preferred hash and restoring but you could progressively migrate a 
file system over (or at least do some testing to see if it's worth it or 
not) by copying and renaming existing trees after changing hash_alg.

Regards,
Bryn.