LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: David Chinner <dgc@sgi.com>
To: Frantisek Rysanek <Frantisek.Rysanek@post.cz>
Cc: linux-kernel@vger.kernel.org
Subject: Re: block layer / FS question: x86_32bit with LBD, 20 TB RAID volume => funny issues
Date: Mon, 10 Mar 2008 09:05:47 +1100	[thread overview]
Message-ID: <20080309220547.GR155407@sgi.com> (raw)
In-Reply-To: <47D06F77.29711.A05566EC@Frantisek.Rysanek.post.cz>

On Thu, Mar 06, 2008 at 10:25:59PM +0100, Frantisek Rysanek wrote:
> A few days ago, I've had my first opportunity to put my hands on a 
> 24bay RAID unit - configured for RAID 60, that's 20 TB of space in a 
> single chunk. I know that RAID units capable of this sort of capacity 
> have been on the market for some time now, so I was somewhat 
> surprised to discover that there are pending issues against Linux...
> 
> The block device is detected/reported just fine.
> I didn't even try Ext3, I know it's not appropriate for this sort of 
> capacity. I've tried Reiser3, and already mkfs.reiserfs (user-space 
> util) refused to create such a big FS. Then I tried XFS. The user-
> space mkfs.xfs had no objections - so far so good. But when I tried 
> to mount the volume thus created, the kernel-space XFS driver 
> (including the one in 2.6.24.2) refused to mount the FS, complaining 
> about the FS being too big to be mounted on this platform.

Sure. the largest address space that can be used on a 32bit platform
with 4k pages is 16TB (2^32 * 2^12 = 2^44 = 16TB). For XFS, that
means metadata can't be placed higher in the filesystem than 16TB,
and seeing as we only have a single address space for metadata, the
filesystem is limited to 16TB. It could be fixed with software
changes, but really there's no excuse for using x86 given how
cheap x86_64 is now.....

> So far I've been using kernels compiled for 32bit mode x86.
> Obviously I have LBD support enabled, and it's always worked 
> flawlessly. Would it be any help if I switched to 64bit mode?
> My machines have been capable of that for a few years now, but so far 
> I had no reason to switch, as the memory capacities installed hardly 
> ever reached 4 GB...

Yes, switching to 64 bit machines will fix this problem as the
address space will now hold 2^64*2^12 bytes.....

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

  parent reply	other threads:[~2008-03-09 22:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-06 21:25 Frantisek Rysanek
     [not found] ` <75b66ecd0803061905n5c06663cv2b75659917461199@mail.gmail.com>
2008-03-07  6:10   ` Frantisek Rysanek
2008-03-07  9:30     ` Andi Kleen
2008-03-07 10:48       ` Frantisek Rysanek
2008-03-09  4:26     ` Lee Revell
2008-03-09 22:05 ` David Chinner [this message]
2008-03-10  4:32   ` Frantisek Rysanek
2008-03-10  9:13 Frantisek Rysanek
2008-03-13 10:14 Frantisek Rysanek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080309220547.GR155407@sgi.com \
    --to=dgc@sgi.com \
    --cc=Frantisek.Rysanek@post.cz \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: block layer / FS question: x86_32bit with LBD, 20 TB RAID volume => funny issues' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).