All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Phillips <phillips@bonn-fries.net>
To: "Ph. Marek" <marek@bmlv.gv.at>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Ideas for TUX2
Date: Wed, 4 Jul 2001 16:31:00 +0200	[thread overview]
Message-ID: <01070416310004.03760@starship> (raw)
In-Reply-To: <3.0.6.32.20010704081621.00921a60@pop3.bmlv.gv.at> <3.0.6.32.20010704095314.009201b0@pop3.bmlv.gv.at>
In-Reply-To: <3.0.6.32.20010704095314.009201b0@pop3.bmlv.gv.at>

On Wednesday 04 July 2001 09:53, Ph. Marek wrote:
> >> Well, my point was, that with several thousand inodes spread over the
> >> disk it won't always be possible to update the inode AND the fbb in one
> >> go. So I proposed the 2nd inode with generation counter!
> >
> >The cool thing is, it *is* possible, read how here:
> >
> >  http://nl.linux.org/~phillips/tux2/phase.tree.tutorial.html
>
> Well, ok. Your split the inode "files" too.
>
> Hmmm...
> That sound more complex than my version (at least now, until I've seen the
> implementation - maybe it's easier because it has less special cases than
> mine).

Yes, it's more complex, but not horribly so.  It's a lot more efficient, and 
that's the point.

> And of course the memory usage on the harddisk is much less with your
> version as you split your inode data and don't have it duplicated.

Yep.

> Well, I hope to see an implementation soon - I'd like to help, even if it's
> only testing.

See you on the list.  By the way, if you want to help out right now, could 
you run some benchmarks my latest early flush patch?  See "[RFC] Early Flush 
with Bandwidth Estimation".

--
Daniel

      reply	other threads:[~2001-07-04 14:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.33L.0107032042220.28737-100000@imladris.rielhom e.conectiva>
2001-07-03  6:25 ` Ideas for TUX2 Ph. Marek
2001-07-03 23:44   ` Rik van Riel
2001-07-04  6:16   ` Ph. Marek
2001-07-04  6:54     ` Daniel Phillips
2001-07-04  7:53     ` Ph. Marek
2001-07-04 14:31       ` Daniel Phillips [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=01070416310004.03760@starship \
    --to=phillips@bonn-fries.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marek@bmlv.gv.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.