On Aug 23, 2002 10:02 -0400, Theodore Ts'o wrote:
> Actually, lsattr isn't printing that information right now. ('i' is
> the immutable flag.)
>
> We could print this information, but arguably users never need to know
> whether or not a directory is hashed or not, since it has no visible
> differences in the behaviour (just in the performance).
I could have sworn I had a patch to print the 'h' flag months ago,
but maybe it didn't make it into your repository.
> > e2fsprogs.sf.net - version 1.28 is very recent and has support for
> > this flag. I'm not sure whether the patch you have has a supported
> > hash function though... This was in flux up to a week ago or so.
>
> As far as the hash function is concerned, as long as it's Christopher
> Li's port of the htree patches to 2.4, which is still using Daniel
> Phillips "dx_hack_hash", you'll be fine. If the patch you have is
> based off of the CVS "features" branch which uses a half-MD4 hash, it
> won't be compatible. Fortunately, as far as I know the CVS "features"
> branch never escaped as a stand-alone patch, so I'm pretty sure you'll
> be all right.
Well, I think the patch Chris posted is based on the features-branch
code (according to his email), so it will probably have half-MD4 as
the hash.
> > there still needs to be some cleanup done (e.g. htree and e2fsck to
> > live happily together).
I was referring to the fact that the current features branch and e2fsck
do not support the same hash functions.
> On the kernel side, the major tasks that need to be done are:
>
> * Support for multiple hash functions, and using the
> superblock field for the default hash function for new
> directories. (Andreas, you were working on code for
> that, right? Is that ready for release yet?)
I have it mostly done, but haven't worked on it for a while. I didn't
know anyone was waiting on this.
> * Adding support for the modified half-MD4 hash which is endian
> independent, and the TEA hash, which should be the
> preferred hash going forward.
If we are looking to use TEA, why even bother with endian-neutral
half-MD4? I don't think _anyone_ has ext3 code which uses that,
and it is not compatible with the existing half-MD4 code either.
We may as well cut out complexity while we have the option to do so.
Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/
