Re: file system technical comparisons

[Hans Reiser <reiser@namesys.com>]

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