linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ted Ts'o <tytso@mit.edu>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: ext4 development <linux-ext4@vger.kernel.org>
Subject: Re: mkfs'ing a 48-bit fs... or not.
Date: Tue, 4 Oct 2011 00:00:33 -0400	[thread overview]
Message-ID: <20111004040033.GM6684@thunk.org> (raw)
In-Reply-To: <4E8A2F3F.30700@sandeen.net>

On Mon, Oct 03, 2011 at 04:55:11PM -0500, Eric Sandeen wrote:
> Has anyone tried mke2fs at its limits?  The latest git tree seems to fail in several ways.
> (Richard Jones reported the initial failure)
> 
> # truncate --size 1152921504606846976 reallybigfile 
> # mke2fs -t ext4 reallybigfile
> 
> first,
> 
> Warning: the fs_type huge is not defined in mke2fs.conf
> 
> (when types "big" and "huge" got added, they never got a mke2fs.conf update?)

It used to be that an undefined file system type didn't flag an error.
It now does, so we should have definitions for them in mke2fs.conf.

> reallybigfile: Not enough space to build proposed filesystem while setting up superblock
> 
> because:
> 
>         fs->group_desc_count = (blk_t) ext2fs_div64_ceil(
>                 ext2fs_blocks_count(super) - super->s_first_data_block,
>                 EXT2_BLOCKS_PER_GROUP(super));
>         if (fs->group_desc_count == 0) {
>                 retval = EXT2_ET_TOOSMALL;
> 
> The div64_ceil returns > 2^32 (2^33, actually), and the cast to blk_t
> (which should be dgrp_t?) turns that into a 0.

Yep, that should be dgrp_t.  Oops.

> Trying it with "-O bigalloc" (which should be automatic at this size,
> I think?) just goes away for a very long time, I'm not sure what it's
> thinking about, or if it's in a loop somewhere (looking now).

Well, we probably do want to engage bigalloc automatically, at some
point (I want to wait until bigalloc is in commonly used kernels, at
least for community distro's).  I'm not sure what the best cluster
size to pick by default should be, though.  16k?  64k?

     	     		       	   	    	  - Ted

  reply	other threads:[~2011-10-04  4:00 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-03 21:55 mkfs'ing a 48-bit fs... or not Eric Sandeen
2011-10-04  4:00 ` Ted Ts'o [this message]
2011-10-04  4:26   ` [PATCH 1/2] Add "big" and "huge" types to mke2fs.conf Theodore Ts'o
2011-10-04  4:27     ` [PATCH 2/2] libext2fs: fix bad cast which causes problems for file systems > 512EB Theodore Ts'o
2011-10-04 11:47       ` Eric Sandeen
2011-10-04 18:05         ` Ted Ts'o
2011-10-04 18:15           ` Eric Sandeen
2011-10-04  5:31   ` mkfs'ing a 48-bit fs... or not Andreas Dilger
2011-10-04  4:03 ` Eric Sandeen
2011-10-04  4:28   ` Ted Ts'o
2011-10-04  7:06 ` Richard W.M. Jones

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=20111004040033.GM6684@thunk.org \
    --to=tytso@mit.edu \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sandeen@sandeen.net \
    /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;
as well as URLs for NNTP newsgroup(s).