linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Ramesh <ramesh@arasan.com>
Cc: ext3-users@redhat.com, linux-ext4@vger.kernel.org,
	A Garg <agarg@arasan.com>, Prashant <prashant@arasan.com>,
	Sridevi <sridevi@arasan.com>
Subject: Re: File System Selection
Date: Wed, 06 May 2009 10:04:19 -0500	[thread overview]
Message-ID: <4A01A6F3.9010306@redhat.com> (raw)
In-Reply-To: <1241609864.806615859@192.168.1.201>

Ramesh wrote:
> Hi Eric,
> 
> Thanks for your prompt and informative reply.
> 
>>>> do you mean sector size of the block device, or block size of
>>>> the fileystem?
> For our device sector size is 4906 bytes. But the maximum allowed
> data chunk to read/write is 512( a.k.a Block size), restricted by
> specification.
> 
> By referring the wiki pages of EXT3
> (http://en.wikipedia.org/wiki/Ext3), I saw the below table.
> 
> Block size       Max file size  Max filesystem size
> 1 KiB            16 GiB         <2 TiB
> 2 KiB            256 GiB        <4 TiB
> 4 KiB            2 TiB          <8 TiB
> 8 KiB[limits 1]  2 TiB          <16 TiB

Above, block size means the filesystem block size.

For ext3, all 32 bits should be safe on recent kernels and userspace, so
I think the max filesystem sizes listed above are too small by half.

IOW, 4k filesystem blocks -> 16T max filesystem size.

> And by taking the values with the table, then for 512 bytes block
> size, Max file system supported is 1 TB only. Please correct me, if I
> assumed wrongly.

you cannot have a 512 byte block size in ext3, 1k is the minimum.

>>>> I guess it doesn't matter much either way, 2^32*512 is 2T.
> 
> In that 32 bit, it using the MSB as signed bit. So it can use maximum
> of 31 bits only. Is this correct?

all 32 bits should be safe now.

>>>> On a 32 bit machine you will be limited to 16T, this is
>>>> actually a page cache limitation.  But 2T should be fine.
> 
> Please clarify me that Ext4 is using a 48 bit addressing. Is this
> necessary to go for 64 bit machines to utilize Ext4 and manage up to
> and including 2TB size file system... Please clarify me.

The ext4 ondisk format does use 48 bits for physical addressing, but
userspace is still 32 bits only even for ext4.

-Eric

> Thanks in advance.
> 
> 
> Regards, Ramesh

       reply	other threads:[~2009-05-06 15:04 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1241609864.806615859@192.168.1.201>
2009-05-06 15:04 ` Eric Sandeen [this message]
2009-04-29  5:33 File System Selection Ramesh
2009-05-05 15:23 ` 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=4A01A6F3.9010306@redhat.com \
    --to=sandeen@redhat.com \
    --cc=agarg@arasan.com \
    --cc=ext3-users@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=prashant@arasan.com \
    --cc=ramesh@arasan.com \
    --cc=sridevi@arasan.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;
as well as URLs for NNTP newsgroup(s).