We removed the htree support since we got to many bug reports.
The feature was experimental and was not strictly necessary
for normal operation.
Damjan Jovanovic has been working on bringing this back and has
fixed three bugs. Copy-pasted from his email:
- Use of '0' instead of 0 to check for null termination in a string, in
function ext2_is_dot_entry() in ext2_lookup.c , thus wrongly searching
further for "." - I am not sure what the consequences are though.
- When ext2_htree_split_dirblock() was shrinking directory entries in
block1, and block1 ended in entries that were moved to block2, it ended up
corrupting the directory because the "last" variable was left pointing to
an invalid entry. This would cause every directory to have a 50% chance of
becoming corrupt per disk block used for the directory after the first
block. My patch changes the order of operations when shrinking, only
copying an entry when it's valid, and only advancing "last" immediately
before the entry is copied, so that "last" always ends up pointing to a
- On every resize of the htree from a depth of 1 to 2, which happens when
the number of files in a directory exceed 7500 or so (exact number depends
on filename lengths and the filesystem block size/hash seed/etc.), a panic
will always happen ("panic: Lock bufwait not exclusively locked @
/usr/src/sys/kern/vfs_bio.c:1317") in ext2_htree_add_entry(), as calling
"relse(dst_bp);" in the "finish:" section is wrong since ownership of the
"struct buf" it points to was transferred from dst_bp to
info.h_levels[1].h_bp which will either relse() it itself or start
background I/O on it. A patch to null out dst_bp after the assignment so
we don't relse() it later is attached.
The differential Revision brings back the support and merges changes proposed by Damjan.