All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phillip Susi <psusi@cfl.rr.com>
To: Andreas Dilger <adilger@dilger.ca>
Cc: linux-ext4@vger.kernel.org
Subject: Re: 64bit filesystem questions
Date: Fri, 10 Jun 2011 11:19:45 -0400	[thread overview]
Message-ID: <4DF23611.7000307@cfl.rr.com> (raw)
In-Reply-To: <692307AB-41C8-4BC7-9D01-E5798CAB3548@dilger.ca>

On 6/9/2011 8:08 PM, Andreas Dilger wrote:
> There is only a single block pointer for each bitmap per group.  That said,
> with flex_bg this is mostly meaningless, since the bitmaps do not have to
> be located in the group, and a flex group is the same as a virtual group
> that is {flex_bg_factor} times as large.

Of course there is only a single pointer because there is only a single 
bitmap.  What does this have to do with limiting the block count to 8 * 
blocksize?

>> 3)  Why does 64bit disable the resize inode?
>
> Because the on-disk format of the resize inode is only suitable for 32-bit
> filesystems (it is an indirect-block mapped file and cannot reserve blocks
> beyond 2^32).  The "future" way to resize filesystems is using the META_BG
> feature, but the ability to use it has not been integrated into the kernel
> or e2fsprogs yet.

Ahh, right... no indirect blocks.  Couldn't and shouldn't the resize 
inode just use extents instead?  Also I thought that META_BG was an idea 
that eventually become FLEX_BG and has been dropped?


  reply	other threads:[~2011-06-10 15:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-09 14:36 64bit filesystem questions Phillip Susi
2011-06-10  0:08 ` Andreas Dilger
2011-06-10 15:19   ` Phillip Susi [this message]
2011-06-10 16:19     ` Andreas Dilger
2011-06-10 17:14       ` Phillip Susi
2011-06-10 17:29         ` Andreas Dilger
2011-06-10 17:45           ` Phillip Susi
2011-06-10 20:37             ` Andreas Dilger
2011-06-10 21:21               ` Phillip Susi

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=4DF23611.7000307@cfl.rr.com \
    --to=psusi@cfl.rr.com \
    --cc=adilger@dilger.ca \
    --cc=linux-ext4@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.