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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 1 Nov 2011 07:47:58 -0400
From:	Theodore Tso <tytso@....EDU>
To:	i@...y.li
Cc:	Theodore Tso <tytso@....EDU>, Andreas Dilger <adilger@...ger.ca>,
	Andreas Dilger <adilger@...mcloud.com>,
	linux-ext4 development <linux-ext4@...r.kernel.org>,
	Alex Zhuravlev <bzzz@...mcloud.com>, Tao Ma <tm@....ma>,
	"hao.bigrat@...il.com" <hao.bigrat@...il.com>
Subject: Re: bigalloc and max file size


On Oct 31, 2011, at 9:10 PM, Coly Li wrote:
> 
>> I assume the issue then is you
>> want to minimize the number of extents, limited by the 15-bit extent
>> length field?
> Not only extents, but also minimize inode table blocks, bitmap blocks.


So this makes no sense to me.  Bigalloc doesn't have any effect on the number of inode table blocks, and while it certainly shrinks the number block allocation bitmap blocks, changing the extent tree format has no effect on the number of bitmap blocks.

Perhaps I'm not making myself clear.  I was trying to figure out the basis for the desire to use units of clusters for the extent length in the extent tree block.    Is that the reason you were so interested in this change of the bigalloc format?   So you could have a smaller extent tree?

>> 
>> What cluster size are you thinking about?
> Currently we test 1MB cluster size. The extreme ideal configuration (of one use case) is, there is only one block group
> on the whole file system. (In this use case) we are willing to try biggest possible cluster size if we are able to.

This is where you have a single file which is nearly as big as the entire file system?   In that case, why are you using an ext4 file system at all?   Why not just use a raw partition instead, plus an auxiliary partition for the smaller files?

I'm not being critical; I'm just trying to understand your use case and constraints.

Regards,

-- Ted

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ