From: Amir Goldstein <amir73il@gmail.com>
To: "Ted Ts'o" <tytso@mit.edu>
Cc: Rogier Wolff <R.E.Wolff@bitwizard.nl>, linux-ext4@vger.kernel.org
Subject: Re: fsck performance.
Date: Mon, 21 Feb 2011 12:31:20 +0200 [thread overview]
Message-ID: <AANLkTikJs8mBHGvHkJAp-aC719aG6QSJaUH-uvwpx0JK@mail.gmail.com> (raw)
In-Reply-To: <20110220234131.GC4001@thunk.org>
On Mon, Feb 21, 2011 at 1:41 AM, Ted Ts'o <tytso@mit.edu> wrote:
> On Mon, Feb 21, 2011 at 12:15:14AM +0100, Rogier Wolff wrote:
>> > BTW, my backup plan was to replace tdb with something else. One of
>> > the candidates I was looking at was sqlite, but rumors of its speed
>> > deficiencies are making me worry that it won't be a good fit. I don't
>> > want to use berk_db because it has a habit of changing API's
>> > regularly, and you can never be sure which version of berk_db
>> > different distributions might be using. One package which I thought
>> > held promise was Koyoto Cabinet, but unfortunately, it's released
>> > under GPLv3, which makes it incompatible with the license used by
>> > e2fsprogs (which has to be GPLv2, since there are a few files which
>> > are shared with the Linux kernel).
>>
What about Tokyo Cabinet? it seems to be released under GPLv2.1.
Isn't it sufficient (or even better suiting) for scratch files?
>> Hmm. I'll take a look.
>
> If you could put a bit of time into this, that would be really great.
> I have a lot of things that I need to do at the moment, and trying to
> improve [scratch_files] performance is something I've known about for
> a while, but I just haven't had time to get to it.
>
> The fact that the problem can be solved by using 64-bit capable CPU's
> and a large swap space has kept this from rising to the top of the
> priority heap, but it is an important use case, since we do have NAS
> boxes that use cheap-sh*t 32-bit processors, and I'd like to be able
> to support them. But I just don't have the time ATM, so if I can
> delegate this out to someone else, that would be really helpful.
>
CTERA uses *affordable* 32-bit processors for it's low-end NAS products,
which still need to be able to complete fsck of a 8TB fs in a reasonable time
(less than the time is takes the customer to loose it's patient and look for
alternative products).
We would be willing to invest resources for this cause,
should we know there is a promising path to follow.
One thing I am not sure I understand is (excuse my ignorance) why is the
swap space solution good only for 64bit processors?
Is it a common knowledge that fsck can require more than 3GB of memory?
If it is common knowledge, do you know of an upper limit (depending on fs size,
no. of inodes, etc)?
Thanks,
Amir.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-02-21 10:31 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 [this message]
2011-02-21 16:04 ` Paweł Brodacki
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=AANLkTikJs8mBHGvHkJAp-aC719aG6QSJaUH-uvwpx0JK@mail.gmail.com \
--to=amir73il@gmail.com \
--cc=R.E.Wolff@bitwizard.nl \
--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).