All of lore.kernel.org
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@MIT.EDU>
To: Ric Wheeler <ric@emc.com>, Matthew Wilcox <matthew@wil.cx>,
	Mark Lord <lkml@rtr.ca>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Jens Axboe <axboe@kernel.dk>, Jeff Garzik <jgarzik>
Subject: Re: What to do about the 2TB limit on HDIO_GETGEO ?
Date: Tue, 25 Mar 2008 16:51:17 -0400	[thread overview]
Message-ID: <20080325205117.GP16358@mit.edu> (raw)
In-Reply-To: <20080325164750.GG16358@mit.edu>

On Tue, Mar 25, 2008 at 12:47:50PM -0400, Theodore Tso wrote:
> 
> Well 2TB, assuming a 4k blocksize, means a block bitmap is 512 megs.
> So at least for ext3, 4GB should be just enough, unless you hit
> certainly really nasty complicated corruptions (i.e. large number of
> blocks claimed by more than one inode, which can happen if an inode
> table is written to the wrong location on disk --- on top of some
> other portion of the inode table), or if the filesystem has a large
> number of files with hard links (such as the case with certain backup
> programs).

Whoops, screwed up my math.  The block bitmap for a 2TB filesystem is
64 megs, not 512 megs.  2*41 / 2**12 / 2**3 == 2**26, or 64mb.  E2fsck
in the worst case will allocate 5 inode bitmaps and 3 block bitmaps,
plus various arrays for directory blocks and keeping track of
refcounts (which are optimized for counnts of 0 and 1, so lots of hard
links will blow up your memory usage, although we do have a tdb option
which helps in that particular case).  So I'd say that most of the
time 3GB of address space should really be enough for a 2TB raid
array, unless you get really pathalogical corruption cases.

							- Ted

WARNING: multiple messages have this Message-ID (diff)
From: Theodore Tso <tytso@MIT.EDU>
To: Ric Wheeler <ric@emc.com>, Matthew Wilcox <matthew@wil.cx>,
	Mark Lord <lkml@rtr.ca>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Jens Axboe <axboe@kernel.dk>, Jeff Garzik <jgarzik@pobox.com>,
	Tejun Heo <htejun@gmail.com>, Greg KH l <gregkh@suse.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	IDE/ATA development list <linux-ide@vger.kernel.org>,
	linux-scsi <linux-scsi@vger.kernel.org>
Subject: Re: What to do about the 2TB limit on HDIO_GETGEO ?
Date: Tue, 25 Mar 2008 16:51:17 -0400	[thread overview]
Message-ID: <20080325205117.GP16358@mit.edu> (raw)
In-Reply-To: <20080325164750.GG16358@mit.edu>

On Tue, Mar 25, 2008 at 12:47:50PM -0400, Theodore Tso wrote:
> 
> Well 2TB, assuming a 4k blocksize, means a block bitmap is 512 megs.
> So at least for ext3, 4GB should be just enough, unless you hit
> certainly really nasty complicated corruptions (i.e. large number of
> blocks claimed by more than one inode, which can happen if an inode
> table is written to the wrong location on disk --- on top of some
> other portion of the inode table), or if the filesystem has a large
> number of files with hard links (such as the case with certain backup
> programs).

Whoops, screwed up my math.  The block bitmap for a 2TB filesystem is
64 megs, not 512 megs.  2*41 / 2**12 / 2**3 == 2**26, or 64mb.  E2fsck
in the worst case will allocate 5 inode bitmaps and 3 block bitmaps,
plus various arrays for directory blocks and keeping track of
refcounts (which are optimized for counnts of 0 and 1, so lots of hard
links will blow up your memory usage, although we do have a tdb option
which helps in that particular case).  So I'd say that most of the
time 3GB of address space should really be enough for a 2TB raid
array, unless you get really pathalogical corruption cases.

							- Ted

  reply	other threads:[~2008-03-25 20:57 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <47E875AD.1000901@rtr.ca>
2008-03-25  4:02 ` What to do about the 2TB limit on HDIO_GETGEO ? Mark Lord
2008-03-25  4:19   ` Andrew Morton
2008-03-25  5:13   ` H. Peter Anvin
2008-03-25 13:37     ` Mark Lord
2008-03-25 13:55       ` H. Peter Anvin
2008-03-25 17:37         ` Mark Lord
2008-03-25 19:25           ` Greg KH
2008-03-25 19:34             ` Randy Dunlap
2008-03-25 20:36               ` H. Peter Anvin
2008-03-25 21:20                 ` Greg KH
2008-03-25 21:26                   ` H. Peter Anvin
2008-03-25 23:00                     ` Greg KH
2008-03-25 23:05                       ` H. Peter Anvin
2008-03-25 23:22                         ` Greg KH
2008-03-27 19:05                     ` Matthew Wilcox
2008-03-26  0:34             ` Mark Lord
2008-03-26  0:54               ` Tejun Heo
2008-03-26  3:38                 ` Greg KH
2008-03-26  4:24                   ` Tejun Heo
2008-03-26  6:04                     ` H. Peter Anvin
2008-03-27 19:29                 ` Kay Sievers
2008-03-27 19:38                   ` H. Peter Anvin
2008-04-11 23:25                     ` Dan Williams
2008-04-15  7:18                       ` Andrew Morton
2008-04-15 13:47                         ` Mark Lord
2008-04-15 14:20                         ` James Bottomley
2008-04-15 18:16                           ` H. Peter Anvin
2008-04-15 23:43                             ` Dan Williams
2008-04-16 20:55                               ` patch sysfs-add-sys-dev-char-block-to-lookup-sysfs-path-by-major-minor.patch added to gregkh-2.6 tree gregkh
2008-04-16 20:55                               ` gregkh
2008-04-16 20:55                                 ` gregkh
2008-03-27 18:51               ` What to do about the 2TB limit on HDIO_GETGEO ? Kay Sievers
2008-03-27 18:55                 ` H. Peter Anvin
2008-03-27 19:03                   ` Kay Sievers
2008-03-25 15:17   ` James Bottomley
2008-03-25 17:31     ` Mark Lord
2008-03-25 19:32       ` James Bottomley
2008-03-25 17:45     ` Greg Freemyer
2008-03-25 17:52       ` Randy Dunlap
2008-03-25 18:09         ` Matthew Wilcox
2008-03-26  9:58           ` Boaz Harrosh
2008-03-30  4:28       ` Matt Domsch
     [not found] ` <alpine.LFD.1.00.0803242254020.2775@woody.linux-foundation.org>
2008-03-25 13:34   ` Mark Lord
2008-03-25 13:51     ` Greg Freemyer
2008-03-25 14:31     ` Ric Wheeler
2008-03-25 15:25       ` Andrew Paprocki
2008-03-25 15:34       ` Matthew Wilcox
2008-03-25 15:48         ` Ric Wheeler
2008-03-25 16:47           ` Theodore Tso
2008-03-25 20:51             ` Theodore Tso [this message]
2008-03-25 20:51               ` Theodore Tso
2008-03-25 20:51             ` Theodore Tso
     [not found] <abhxL-xC-7@gated-at.bofh.it>
     [not found] ` <abhRd-1bf-15@gated-at.bofh.it>
     [not found]   ` <ablib-2zv-65@gated-at.bofh.it>
     [not found]     ` <abn0B-735-35@gated-at.bofh.it>
     [not found]       ` <abna7-7jK-3@gated-at.bofh.it>
     [not found]         ` <abo6b-11J-9@gated-at.bofh.it>
     [not found]           ` <aboSP-2Wf-29@gated-at.bofh.it>
     [not found]             ` <aboSP-2Wf-27@gated-at.bofh.it>
     [not found]               ` <abqrq-6eX-29@gated-at.bofh.it>
     [not found]                 ` <abqrq-6eX-27@gated-at.bofh.it>
     [not found]                   ` <abqKM-6Ka-13@gated-at.bofh.it>
2008-03-26 11:30                     ` Bodo Eggert
2008-03-26 11:30                     ` Bodo Eggert
2008-03-26 11:30                       ` Bodo Eggert
2008-03-27  3:52                       ` Greg KH
2008-03-27  4:57                         ` H. Peter Anvin
2008-03-27 14:45                         ` Mark Lord
2008-03-27 15:15                           ` Greg KH

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=20080325205117.GP16358@mit.edu \
    --to=tytso@mit.edu \
    --cc=axboe@kernel.dk \
    --cc=lkml@rtr.ca \
    --cc=matthew@wil.cx \
    --cc=ric@emc.com \
    --cc=torvalds@linux-foundation.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.