All of lore.kernel.org
 help / color / mirror / Atom feed
From: venom@sns.it
To: Hans Reiser <reiser@namesys.com>
Cc: Steve Glines <sglines@is-cs.com>, <linux-kernel@vger.kernel.org>
Subject: Re: file system technical comparisons
Date: Wed, 7 Jan 2004 00:48:14 +0100 (CET)	[thread overview]
Message-ID: <Pine.LNX.4.43.0401070036190.19759-100000@cibs9.sns.it> (raw)
In-Reply-To: <3FFAA4F6.5040501@namesys.com>

On Tue, 6 Jan 2004, Hans Reiser wrote:

> balanced trees squish things together at every modification of the
> tree.  Dancing trees squish things together when they get low on ram,
> which is less often.  this means that we can afford to squish tighter
> because we do it less often.

This is generally true except some maior cases.

A SAP server, for example, is "always" low on ram, not because of oracle, but
because how the "disp+work" processes work.

Another case I am thinking is a tibco server, when processes start to fork
because of a lot of incoming messages from everywhere, and the DB really start
to write a lot of stuff (all small writes).

I am curious to make some test in those cases.

Another think I am thinking about is an MC^2 lun. If all the I/O is resolved
inside of the EMC cache, BTrees could be better than dancing trees? In fact
in this case what matters is the CPU power you are using, since you de facto
talk just with EMC cache.

I know those are strange scenarios, but those are the scenarios I am actually
working with. Since those are not typical situations, I think right now they are
ininfluent, but in the future maybe more people will have to deal with them.

Anyway untill I do not make some serious experiment mine are just
speculations.

Luigi


  reply	other threads:[~2004-01-06 23:48 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-02 21:38 file system technical comparisons Steve Glines
2004-01-05  9:42 ` venom
2004-01-05 11:04   ` Hans Reiser
2004-01-05 17:08     ` venom
2004-01-05 17:18       ` Hans Reiser
2004-01-06 11:58         ` venom
2004-01-06 12:07           ` Hans Reiser
2004-01-06 23:48             ` venom [this message]
2004-01-07  9:13               ` Hans Reiser
2004-01-05 17:37   ` Randy.Dunlap
2004-01-06 12:04     ` venom
2004-01-06 14:55       ` Hans Reiser
2004-01-06 20:32         ` Theodore Ts'o
2004-01-09 19:32 ` Stewart Smith

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=Pine.LNX.4.43.0401070036190.19759-100000@cibs9.sns.it \
    --to=venom@sns.it \
    --cc=linux-kernel@vger.kernel.org \
    --cc=reiser@namesys.com \
    --cc=sglines@is-cs.com \
    /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.