lkml.org 
[lkml]   [2004]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: file system technical comparisons
venom@sns.it wrote:

>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.
>
>
even if it is always low on ram, the memory pressure signal from VM is
still less often than the tree modification because we squish in big
batches.

>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?
>
no, dancing trees would still fit in that cache and still be more cpu
efficient

> 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
>
>
>
>
>
there are flaws in the reiser4 algorithms, but the dancing tree concept
is a good one. We are currently experimentally encountering various
oddities needing fixing. For instance, if your working set is just
barely too large for ram, we have a tendency to flush too many pages out
of ram and make you wait for us to do so. this is fixable, and being
discussed now amongst us.

--
Hans


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:59    [W:0.074 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site