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

Re: Ext3 indexed directory extension.

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

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