i have some older filesystems with Default directory hash: tea
is change them to "half_md4" safe? tune2fs -E hash_alg=half_md4 /dev/sdc1
they are all created short before the following commit: http://git.whamcloud.com/?p=tools/e2fsprogs.git;a=commitdiff_plain;h=d1070d9...
Reindl Harald wrote:
i have some older filesystems with Default directory hash: tea
is change them to "half_md4" safe? tune2fs -E hash_alg=half_md4 /dev/sdc1
they are all created short before the following commit: http://git.whamcloud.com/?p=tools/e2fsprogs.git;a=commitdiff_plain;h=d1070d9...
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 have an application which creates about 26k files per day in a directory, and performance gets a little iffy just before midnight.
No, I'm not going to rewrite it to work differently, I would have to do that for each update. Yes, it's already on SSD.
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.
Bryn M. Reeves wrote:
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.
Thank you for the information below, I can certainly do a test and see if it makes a big difference, some testing will be needed.
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.
Am 09.01.2013 19:36, schrieb 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)
ok, this is the point i liked to get confirmed
fsck.ext4 -Df promises to benefit also for existing directories if i am not completly wrong here (see pararaph from man fsck.ext4)
i tried it already in a virtual machine which would be easy to rcvober and all seems to be fine, but hopefully some of the FS specialists / developers are reading here and can comment ________________________________________________________
-D Optimize directories in filesystem. This option causes e2fsck to try to optimize all directories, either by reindexing them if the filesystem supports directory indexing, or by sorting and compressing directories for smaller directories, or for filesystems using traditional linear directories.
-
Bill Davidsen -
Bryn M. Reeves -
Reindl Harald