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:	Mon, 31 Oct 2011 12:22:23 -0400
From:	Ted Ts'o <tytso@....edu>
To:	Andreas Dilger <adilger@...ger.ca>
Cc:	"i@...y.li" <i@...y.li>, 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 Mon, Oct 31, 2011 at 10:08:20AM -0600, Andreas Dilger wrote:
> On 2011-10-31, at 4:22 AM, Theodore Tso <tytso@....EDU> wrote:
> For cluster file systems, such as when you might build Hadoop on top
> > of ext4, there's no real advantage of using RAID arrays as opposed
> > to having single file systems on each disk.  In fact, due to the
> > specd of being able to check multiple disk spindles in parallel,
> > it's advantageous to build cluster file systems on single disk
> > file systems.
> 
> For Lustre at least there are a number of reasons why it uses large
> RAID devices to store the data instead of many small devices: -
> fewer devices that need to be managed. Lustre runs on systems with
> more than 13000 drives, and having to manage connection state for
> that many internal devices is a lot of overhead.

Well, per the discussion on the ext4 call, with Lustre hardware
multiple RAID LUN's get used, so while they might have tens of
petabytes of data, it is still split across a thousand hardware LUN's
or so.  So there is a middle ground between "put all of your 13000
devices on a single hardware RAID LUN", and "use 13000 file systems".
And in that middle ground, it seems surprising that someone would be
bumping into the the 1EB file system limit offered by ext4.

I'm curious why TaoBao is so interested in changing the extent
encoding for bigalloc file systems.  Currently we can support up to 1
EB worth of physical block numbers, and 16TB of logical block numbers.
Are you concerned about bumping into the 1 EB file system limit?  Or
the 16 TB file size limit?  Or something else?

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