public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: David Chinner <dgc@sgi.com>
Cc: Christian Guggenberger
	<christian.guggenberger@physik.uni-regensburg.de>,
	xfs@oss.sgi.com
Subject: Re: mount failed after xfs_growfs beyond 16 TB
Date: Fri, 03 Nov 2006 08:54:43 -0600	[thread overview]
Message-ID: <454B5833.9030008@sandeen.net> (raw)
In-Reply-To: <20061103004142.GI8394166@melbourne.sgi.com>

David Chinner wrote:
> On Thu, Nov 02, 2006 at 06:26:08PM +0100, Christian Guggenberger wrote:
>> Hi,
>>
>> a colleague recently tried to grow a 16 TB filesystem (x86, 32bit) on
>> top of lvm2 to 17TB. (I am not even sure if that's supposed work with
>> linux-2.6, 32bit)
> 
> Not supported - any metadata access past 16TB will wrap the 32 bit page cache
> index for the metadata address space and you'll corrupt the filesystem.


Ohhhh right.  I've been in x86_64 land for too long, sorry for the earlier false 
assertion....  :(

xfs guys, if it's not there already (and I don't see it from a quick look..) 
growfs -really- should refuse (in the kernel) to grow a filesystem past 16T on a 
32-bit machine, just as we refuse to mount one.  something like this in 
xfs_growfs_data_private:

#if XFS_BIG_BLKNOS     /* Limited by ULONG_MAX of page cache index */
         if (unlikely(
             (nb >> (PAGE_SHIFT - sbp->sb_blocklog)) > ULONG_MAX) {
#else                  /* Limited by UINT_MAX of sectors */
         if (unlikely(
             (nb << (sbp->sb_blocklog - BBSHIFT)) > UINT_MAX) {
#endif
                 cmn_err(CE_WARN,
                         "new filesystem size too large for this system.");
                 return XFS_ERROR(E2BIG);
         }

and something similar in xfs_growfs_rt ?

-Eric

  reply	other threads:[~2006-11-03 14:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-02 17:26 mount failed after xfs_growfs beyond 16 TB Christian Guggenberger
2006-11-02 18:38 ` Eric Sandeen
2006-11-03  9:32   ` Christian Guggenberger
2006-11-03 12:34     ` David Chinner
2006-11-03 15:44       ` Christian Guggenberger
2006-11-03 15:54         ` Eric Sandeen
2006-11-06 13:41         ` Christian Guggenberger
2006-11-07  8:17         ` David Chinner
2006-11-03  0:41 ` David Chinner
2006-11-03 14:54   ` Eric Sandeen [this message]
2006-11-06  1:15     ` Timothy Shimmin
2006-11-06  3:25       ` Eric Sandeen

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=454B5833.9030008@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=christian.guggenberger@physik.uni-regensburg.de \
    --cc=dgc@sgi.com \
    --cc=xfs@oss.sgi.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox