[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: ext3 2.4.21 htree tests

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:

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 ..
umount /mnt

Comment out the "tune2fs -O dir_index" line, and the timings speak for

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

(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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]