Message-id: <20090106031625.GB3932@webber.adilger.int>
Date:	Mon, 05 Jan 2009 20:16:25 -0700
From:	Andreas Dilger <adilger@....com>
To:	Peng tao <bergwolf@...il.com>
Cc:	Zhang Xiliang <zhangxiliang@...fujitsu.com>,
	Theodore Tso <tytso@....edu>,
	Toshiyuki Okajima <toshi.okajima@...fujitsu.com>,
	linux-ext4@...r.kernel.org
Subject: Re: Problems with the max value for create directory

On Dec 29, 2008  21:47 +0800, Peng tao wrote:
> I got a question about this.
> Since htree is a potential limitation for subdirectories. Is there a
> reason why EXT4_LINK_MAX is applied when fs hasn't dir_index but
> ignored when fs has dir_index(by the following code)?
> 
> #define is_dx(dir) (EXT4_HAS_COMPAT_FEATURE(dir->i_sb, \
> 				      EXT4_FEATURE_COMPAT_DIR_INDEX) && \
> 		      (EXT4_I(dir)->i_flags & EXT4_INDEX_FL))
> #define EXT4_DIR_LINK_MAX(dir) (!is_dx(dir) && (dir)->i_nlink >= EXT4_LINK_MAX)

Because without the dir_index feature the largest usable directory size
is only about 10k-20k files before the O(n^2) insertion performance is
so bad that the directory is useless.

> On Wed, Dec 24, 2008 at 9:18 AM, Zhang Xiliang
> <zhangxiliang@...fujitsu.com> wrote:
> > Theodore Tso 写道:
> >
> >>
> >> So that's not it.  The problem is that indexed diretories have a limit
> >> that only allows the trees to be two levels deep.  The fanout is
> >> normally big enough that this is effectively not a problem, but if you
> >> use very long filenames, and a 1k blocksize, you will run into this
> >> limit much more quickly.  So the problem is not the number of sub
> >> directories, but the maximum depth of the htree allowed in Daniel
> >> Phillips' relatively restricted implementation.  Note that with a 4k
> >> block filesystem, the limits get expanded by a factor of 4 cubed, or
> >> 64.  And most of the time users aren't maximal length named directory
> >> entries, which further pushes the limit out in the normal case.
> >>
> >> It in theory would be possible to relax this restriction, using a more
> >> advanced htree implementation and a feature flag to allow backwards
> >> compatibility with older kernels that only support the maximal depth.
> >> Andreas has a prototype kernel implementation which in theory could be
> >> added to ext4.  It hasn't been high on my priority list to complete,
> >> but if someone else really finds this limit to be annoying, it is a
> >> project they might try to complete.
> >>
> >> Were you writing this test program because this is a realistic
> >> situation for your application, or just to explore the limits of ext4?
> >>
> >
> > Thanks for explanation.
> >
> > I see the limit of ext4 subdirectory. The test program originally tests it.
> > But I fail and find the limit of the htree.
> >
> > I think it may be annoying. Somebody may be puzzled for the two limits.
> > The limit of the htree should be greater than the limit of ext4
> > subdirectory.
> >
> > --
> > Regards
> > Zhang Xiliang
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> > the body of a message to majordomo@...r.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> 
> 
> 
> -- 
> Cheers,
> 
> Bergwolf
> 
> ................
> Rodney Dangerfield  - "The way my luck is running, if I was a
> politician I would be honest."
> N?????r??y????b?X??ǧv?^?)޺{.n?+????{?{.x?{ay?.ʇڙ?,j.??f???h???z?.?w???.???j:+v???w?j?m????.????zZ+?????ݢj"??!

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists