linux-ext4 - Re: Problems with the max value for create directory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6149e97b0812290547r6e487caap46c0ec77ccc28709@mail.gmail.com>
Date:	Mon, 29 Dec 2008 21:47:15 +0800
From:	"Peng tao" <bergwolf@...il.com>
To:	"Zhang Xiliang" <zhangxiliang@...fujitsu.com>
Cc:	"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

Hi, guys

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)


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."