The obvious thing to do is to do the tests with and without htree enabled, and compare the results. For large files, the results should be painfully obvious. This is the test I generally use for regression testing ext3: #!/bin/sh dd if=/dev/zero of=test.img bs=8k count=30000 mke2fs -j -F -b 1024 -g 1024 -N 1200000 test.img tune2fs -O dir_index test.img mount -t ext3 -o loop test.img /mnt pushd /mnt mkdir test test2 test3 cd test time seq -f "%06.0f" 1 100 | xargs touch cd .. cd test2 time seq -f "%06.0f" 1 10000 | xargs touch cd .. cd test3 time seq -f "%06.0f" 1 100000 | xargs touch cd .. popd umount /mnt Comment out the "tune2fs -O dir_index" line, and the timings speak for themselves.... If you don't see any differences in time, one obvious thing to check is to make sure that you're using a kernel that actually has the htree patches applied. The dir_index flag is a compatible feature enhancement, which means that that non-htree-capable kernels will happily mount a kernel with the dir_index flag without making any kind of comment or complaint. They will simply not have the htree enhancements. (And when a non-htree capable kernel modifies a directory, they will clear the htree flag on that directory. So the access to that directory will perform correctly on once you remount it on an htree-capable kernel, but you won't see the performance speedups any more. In order to restore the htree data structures on that directory, you will need to run "e2fsck -fD" again. You can see whether or not a directory has valid htree strcutures by using the lsattr command.) - Ted _______________________________________________ Ext3-users@redhat.com https://www.redhat.com/mailman/listinfo/ext3-users
