On Saturday 15 March 2008 14:33, Pavel Machek wrote:
quoted text
> On Sat 2008-03-15 12:22:47, Daniel Phillips wrote:
> > On Saturday 15 March 2008 06:32, Pavel Machek wrote:
> > > On Wed 2008-03-12 22:50:55, Daniel Phillips wrote:
> > > > On Wednesday 12 March 2008 23:30, David Newall wrote:
> > > > > Daniel Phillips wrote:
> > > > > >> Your idea seems predicated on throwing large amounts of RAM at the
> > > > > >> problem.  What I want to know is this: Is it really 25 times faster than
> > > > > >> ext3 with an equally huge buffer cache?
> > > > > >
> > > > > > Yes.
> > > > > 
> > > > > Well, that sounds convincing.  Not.  You know this how?
> > > > 
> > > > By measuring it.  time untar -xf linux-2.2.26.tar; time sync
> > > 
> > > Thats cheating. Your ramback ignores sync.
> > > 
> > > Just time it against ext3 _without_ doing the sync. That's still more
> > > reliable than what you have.
> > 
> > No, that allows ext3 to cheat, because ext3 does not supply any means
> > of flushing its cached data to disk in response to loss of line power,
> > and then continuing on in a "safe" mode until line power comes back.
> 
> Ok, it seems like "ignore sync/fsync unless on UPS power" is what you
> really want? That should be easy enough to implement, either in
> kernelor as a LD_PRELOAD hack.

Sure, let's try it and then we will have a race.  I would be happy to
lose that race, but... let's just see who wins.

quoted text
> So... untar with    sync is fair benchmark against ramback on UPS power
> and   untar without sync is fair benchmark against ramback on AC power.
> 
> But you did untar with sync                against ramback on AC power.
> 
> That's wrong.

It is consistent and correct.  You need to supply the missing features
that ramback supplies before you have a filesystem-level solution.  I
really encourage you to try it, then we can compare the two approaches
with both of them fully working.

Daniel
--
unsubscribe notice
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/