From: Nikita Danilov <Nikita@Namesys.COM>
To: torvalds@transmeta.com (Linus Torvalds)
Cc: linux-kernel@vger.kernel.org
Subject: Re: [BK][PATCH] Reiser4, will double Linux FS performance, pleaseapply
Date: Fri, 1 Nov 2002 13:59:22 +0300 [thread overview]
Message-ID: <15810.24202.287346.658635@laputa.namesys.com> (raw)
In-Reply-To: <apt0bs$3sg$1@penguin.transmeta.com>
Linus Torvalds writes:
> In article <3DC1D9D0.684326AC@digeo.com>,
> Andrew Morton <akpm@digeo.com> wrote:
> >
> >But it should be done based on "feature equivalency". By default,
> >ext3 uses ordered data writes. Data is written to disk before
> >the metadata to which that data refers is committed to journal.
>
> Andrew, that's not necessarily a _good_ feature.
>
> Journaling is _not_ a great idea. There are other approaches to
> handling atomicity than journaling, like phase trees, that give
> equivalent atomicity guarantees without having to write out extra stuff,
> or even impose a very strict ordering between data and meta-data.
>
> I didn't read the reiser papers yet, but from Hans' description it
> sounds like reiser4 gives all the guarantees ext3 does with ordered
> writes, _and_ they get good performance.
Reiser4 uses "wandered logs" that are similar to phase-tree or things
that are called "shadows" or "side files" in the data bases world.
Idea is that most blocks with file system data (and meta-data) are
accessed by first reading their block number from some other "parent"
block (like indirect block in ext2). Now, if block is modified during
transaction *and* its parent block is also dirty, one can avoid writing
copy of block into the journal by:
- allocating new block number ("wandered block")
- storing modified content in the newly allocated wandered block
- updating parent block to point to the new location
Old block is now unreachable from the parent, and if its block number is
stored somewhere in the journal one can use it for recovery.
Reiser4 balanced tree lends itself nicely into this model, of course.
Usual problem with such techniques is that they tend to destroy packing
due to frequent relocations. But in reality this can be used exactly for
the purpose of improving packing, if allocation of wandered blocks if
delayed for sufficiently long time (like until transaction commit).
>
> (In fact, from the description it sounds like it gives _more_ guarantees
> than even ext3 with ordered writes, in that it gives transactional
> behaviour for arbitrary writes. Maybe I should read the paper).
>
> Linus
Nikita.
> -
next prev parent reply other threads:[~2002-11-01 10:53 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-31 21:23 [BK][PATCH] Reiser4, will double Linux FS performance, please apply Hans Reiser
2002-10-31 22:34 ` Dieter Nützel
2002-10-31 22:47 ` Hans Reiser
2002-11-01 1:17 ` [BK][PATCH] Reiser4, will double Linux FS performance, pleaseapply Andrew Morton
2002-11-01 1:27 ` Andrew Morton
2002-11-01 1:27 ` Hans Reiser
2002-11-01 1:33 ` Andrew Morton
2002-11-01 1:44 ` Dieter Nützel
2002-11-01 1:55 ` Hans Reiser
2002-11-01 10:23 ` Tomas Szepe
2002-11-01 17:19 ` Alexander Zarochentcev
2002-11-02 13:24 ` Tomas Szepe
2002-11-04 11:00 ` Nikita Danilov
2002-11-04 19:56 ` Andreas Dilger
2002-11-05 7:30 ` reiser
2002-11-05 8:28 ` Alexander Zarochentcev
2002-11-05 8:44 ` reiser
2002-11-05 8:49 ` Alexander Zarochentcev
2002-11-05 21:08 ` reiser
2002-11-05 9:29 ` Andreas Dilger
2002-11-05 21:39 ` reiser
2002-11-05 9:59 ` Tomas Szepe
2002-11-05 10:08 ` Alexander Zarochentcev
2002-11-05 10:23 ` Tomas Szepe
2002-11-05 10:46 ` Nikita Danilov
2002-11-02 13:38 ` Tomas Szepe
2002-11-04 12:02 ` Nikita Danilov
2002-11-04 17:10 ` Tomas Szepe
2002-11-04 17:53 ` Nikita Danilov
2002-11-04 18:10 ` Tomas Szepe
2002-11-01 4:36 ` Linus Torvalds
2002-11-01 10:59 ` Nikita Danilov [this message]
[not found] <877555917@toto.iv>
2002-11-05 23:09 ` Peter Chubb
2002-11-06 1:33 ` reiser
2002-11-06 14:25 ` Daniel Egger
2002-11-07 17:19 ` Pavel Machek
2002-11-07 16:58 ` Bill Davidsen
2002-11-06 18:37 Tom Reinhart
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=15810.24202.287346.658635@laputa.namesys.com \
--to=nikita@namesys.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®