Messages in this thread | | | Date | Wed, 07 Jan 2004 12:13:06 +0300 | From | Hans Reiser <> | Subject | Re: 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/
| |