From: "Paweł Brodacki" <pawel.brodacki@googlemail.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: "Ted Ts'o" <tytso@mit.edu>, Rogier Wolff <R.E.Wolff@bitwizard.nl>,
linux-ext4@vger.kernel.org
Subject: Re: fsck performance.
Date: Mon, 21 Feb 2011 17:04:26 +0100 [thread overview]
Message-ID: <AANLkTinWOSBqkXhgOa4qdfK+iiLcJSP9LeZaYmUHH9KF@mail.gmail.com> (raw)
In-Reply-To: <AANLkTikJs8mBHGvHkJAp-aC719aG6QSJaUH-uvwpx0JK@mail.gmail.com>
2011/2/21 Amir Goldstein <amir73il@gmail.com>:
> One thing I am not sure I understand is (excuse my ignorance) why is the
> swap space solution good only for 64bit processors?
It's an address space limit on 32 bit processors. Even with PAE the
user space process still won't have access to more than 2^32 bits,
that is 4 GiB of memory. Due to practical limitations (e.g. kernel
needing some address space) usually a process won't have access to
more than 3 GiB.
> Is it a common knowledge that fsck can require more than 3GB of memory?
It is, for a given value of common. Disk sizes exploded and there have
been reports of people running out of memory on 32 bit boxes with
terabyte-sized filesystems for several years now. I did a bit of
googling and found descriptions of such case from 2008.
> If it is common knowledge, do you know of an upper limit (depending on fs size,
> no. of inodes, etc)?
>
I vaguely remember some estimation of memory requirements of fsck
being given somewhere, but I'm not able to find the posts now :(.
next prev parent reply other threads:[~2011-02-21 16:04 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-20 9:06 fsck performance Rogier Wolff
2011-02-20 17:09 ` Ted Ts'o
2011-02-20 19:34 ` Ted Ts'o
2011-02-20 21:55 ` Rogier Wolff
2011-02-20 22:20 ` Ted Ts'o
2011-02-20 23:15 ` Rogier Wolff
2011-02-20 23:41 ` Ted Ts'o
2011-02-21 10:31 ` Amir Goldstein
2011-02-21 16:04 ` Paweł Brodacki [this message]
2011-02-21 18:00 ` Andreas Dilger
2011-02-22 10:20 ` Rogier Wolff
2011-02-22 13:36 ` Rogier Wolff
2011-02-22 13:54 ` Rogier Wolff
2011-02-22 16:32 ` Andreas Dilger
2011-02-22 22:13 ` Ted Ts'o
2011-02-23 4:44 ` Rogier Wolff
2011-02-23 11:32 ` Theodore Tso
2011-02-23 20:53 ` Rogier Wolff
2011-02-23 22:24 ` Andreas Dilger
2011-02-23 23:17 ` Ted Ts'o
2011-02-24 0:41 ` Andreas Dilger
2011-02-24 8:59 ` Rogier Wolff
2011-02-24 7:29 ` Rogier Wolff
2011-02-24 8:59 ` Amir Goldstein
2011-02-24 9:02 ` Rogier Wolff
2011-02-24 9:33 ` Amir Goldstein
2011-02-24 23:53 ` Rogier Wolff
2011-02-25 0:26 ` Daniel Taylor
2011-02-23 2:54 ` Rogier Wolff
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=AANLkTinWOSBqkXhgOa4qdfK+iiLcJSP9LeZaYmUHH9KF@mail.gmail.com \
--to=pawel.brodacki@googlemail.com \
--cc=R.E.Wolff@bitwizard.nl \
--cc=amir73il@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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).