From: kashani <kashani-list@badapple.net>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Filesystem with lowest CPU load, acceptable emerge performance, and stable?
Date: Wed, 07 Sep 2011 15:15:47 -0700 [thread overview]
Message-ID: <4E67ED13.30201@badapple.net> (raw)
In-Reply-To: <CAA2qdGWhMzc4JYm_xKqfRiG8eRFs5Z1-uqQzxKNWpu4a5PMQGA@mail.gmail.com>
On 9/7/2011 5:25 AM, Pandu Poluan wrote:
> On Wed, Sep 7, 2011 at 01:15, kashani<kashani-list@badapple.net> wrote:
>> On 9/6/2011 10:26 AM, Pandu Poluan wrote:
>>>
>>> So, can anyone recommend me a filesystem that fulfills my following needs:
>>>
>>> Scenario: vFirewall (virtual Firewall) that is going to be deployed at
>>> my IaaS Cloud Provider.
>>>
>>> Disk I/O Characteristic: Occasional writes during 'normal' usage,
>>> once-a-week eix-sync + emerge -avuD
>>>
>>> Priority: Stable (i.e., less chance of corruption), least CPU usage.
>>>
>>> My Google-Fu seems to indicate either XFS or JFS; what do you think?
>>
>> I think it's a useless local optimization for no real world gain
>> which only increases the complexity of your systems. Use the same filesystem
>> you use on all your other servers.
>>
>
> Well, for all my other servers, I standardized on ext4.
>
> Since a vFirewall have to perform lots of packet-juggling, I'd rather
> dedicate the CPU time to the kernel rather than the HD I/O.
>
> Of course, a vFirewall needs to be updated every now and then, but
> everytime an update is called for, it should not overly tax the CPU
> and degrade the netfilter framework.
>
> Rgds,
You are making my point for me, but not realizing the end result of the
logic. There isn't any filesystem change that is going to affect CPU
usage by more than a few percentage points in the use case you've
described. Rsync, portage, and gcc use a massive amount of CPU compared
to the amount the filesystem changes will use other than brief points
during the rsync. Additionally most benchmarks are testing filesystem
throughput and comparing it to CPU. Because disk IO isn't under pressure
in your scenario you're unlikely to see the pathological use of CPU that
can highlight the differences between filesystems.
That said, you have a few reasonable choices.
1. Move to a binary distro
2. Use buildpkg on a clone of this server and only install packages on
your Firewall.
3. NFS mount /usr/portage when you need it and dist build on another server
4. Don't upgrade
5. Get a firewall server with more CPU so that it doesn't matter
6. Script a new firewall server install every x months and swap it into
place and drop the original server.
7. Some combination of the above.
kashani
next prev parent reply other threads:[~2011-09-07 22:17 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-06 17:26 [gentoo-user] Filesystem with lowest CPU load, acceptable emerge performance, and stable? Pandu Poluan
2011-09-06 17:52 ` [gentoo-user] " Pandu Poluan
2011-09-06 18:07 ` Florian Philipp
2011-09-06 18:15 ` [gentoo-user] " kashani
2011-09-07 12:25 ` Pandu Poluan
2011-09-07 22:15 ` kashani [this message]
2011-09-08 7:52 ` Pandu Poluan
2011-09-08 22:26 ` kashani
2011-09-06 18:55 ` Permjacov Evgeniy
2011-09-06 19:18 ` Michael Mol
2011-09-06 19:24 ` James Broadhead
2011-09-07 12:06 ` Florian Philipp
2011-09-07 12:23 ` Pandu Poluan
2011-09-07 12:28 ` Pandu Poluan
2011-09-07 21:24 ` Jesús J. Guerrero Botella
2011-09-09 7:36 ` Andrea Conti
2011-09-10 5:43 ` Walter Dnes
2011-09-11 21:02 ` Jesús J. Guerrero Botella
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=4E67ED13.30201@badapple.net \
--to=kashani-list@badapple.net \
--cc=gentoo-user@lists.gentoo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox