lkml.org 
[lkml]   [2004]   [Jan]   [7]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateWed, 07 Jan 2004 12:13:06 +0300
FromHans Reiser <>
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 12:59    [from the cache]
©2003-2008