public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Andrea Conti <alyf@alyf.net>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Filesystem with lowest CPU load, acceptable emerge performance, and stable?
Date: Fri, 09 Sep 2011 09:36:03 +0200	[thread overview]
Message-ID: <4E69C1E3.9050602@alyf.net> (raw)
In-Reply-To: <CAA2qdGVMWtq2jxECcd9ceppT-9jmo3gXbw6f7dhx1GjtOfKGkQ@mail.gmail.com>

> 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?

IMHO a firewall (physical or virtual) is something that fits strictly
into the "appliance" category. It must do only one thing and do it well,
with as little complexity and maintenance overhead as possible. Why in
the world would anyone want to run gentoo (which among the rest needs
portage and a whole compiler stack) -- or for that matter any other
full-fledged linux distribution -- on something like that in production
is beyond me...

That said, XFS and JFS are targeted at completely different use cases
and are way too complex for your scenario. Without appropriately-sized
hardware I'm not even sure XFS fits in the "stable" category. Stick to
ext3, keeping an eye on the inode count for /usr/portage as the default
value on a small partition probably won't be enough.

Fs-related CPU usage in a firewall (which has nearly zero disk activity
when up and running) is mostly a non-issue unless you need some form of
heavy logging or you're doing something wrong.

Weekly updates, on the other hand are exposing you to the risk of random
breakages and -- if you compile from source -- are going to cost you a
serious amount of CPU. My advice would be to limit updates to those
fixing known vulnerabilities, and even then compiling somewhere else and
doing binary installs would be preferable.

andrea




  parent reply	other threads:[~2011-09-09  7:37 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
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 [this message]
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=4E69C1E3.9050602@alyf.net \
    --to=alyf@alyf.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