From: Hans Reiser <reiser@namesys.com>
To: "Markus Törnqvist" <mjt@nysv.org>
Cc: Alex Zarochentsev <zam@namesys.com>,
Will Smith <will@willsmith.org>,
reiserfs-list@namesys.com
Subject: Re: Benchmark : ext3 vs reiser4 and effects of fragmentation.
Date: Thu, 16 Sep 2004 10:26:11 -0700 [thread overview]
Message-ID: <4149CCB3.1030001@namesys.com> (raw)
In-Reply-To: <20040916155248.GM26192@nysv.org>
Markus Törnqvist wrote:
>On Thu, Sep 16, 2004 at 07:38:36PM +0400, Alex Zarochentsev wrote:
>
>
>
>>We are not going to add more intelligence to the in-kernel repacker module but
>>design an interface between repacker and user-space programs and implement
>>reisizing alg. in user-space.
>>
>>
>
>This sounds a bit fishy; is it about having two repackers then?
>One in kernelspace and one in userspace?
>Will the kernelspace one be obsoleted?
>
>
The kernel will perform transactions requested by user space. These
transactions will be composed by the user space program.
We will start with the simple algorithm we currently use, and then Zam
and I will go read Knuth and Woods and the web to seriously research
sorting algorithms which we haven't done yet.
>>>>unmergable units shouldn't be problem for the reiser4 kernel code.
>>>>
>>>>
>>>What are their significance; what do they mean?
>>>
>>>
>>two extent units (start1, len1), (start2, len2) can be merged into one (start1,
>>len1 + len2) because start1 + len1 == start2. I think no reiser4 kernel code
>>depends on that mergable extents do not exist.
>>
>>
>
>Unmergable units are then (start1 + len1) != start2 because the repacker
>messed this up?
>
>The kernel finds the extent units from their "old places" without optimizing
>them to one unit?
>
>
>
next prev parent reply other threads:[~2004-09-16 17:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-15 22:02 Benchmark : ext3 vs reiser4 and effects of fragmentation Will Smith
2004-09-16 8:52 ` Alex Zarochentsev
2004-09-16 13:08 ` mjt
2004-09-16 14:50 ` Will Smith
2004-09-16 15:03 ` mjt
2004-09-16 17:16 ` Hans Reiser
2004-09-16 15:38 ` Alex Zarochentsev
2004-09-16 15:52 ` mjt
2004-09-16 17:26 ` Hans Reiser [this message]
2004-09-16 18:38 ` Alex Zarochentsev
2004-09-16 19:00 ` mjt
2004-09-16 19:05 ` Chris Mason
2004-09-17 2:29 ` Hans Reiser
2004-09-17 17:01 ` Philippe Gramoullé
2004-09-16 15:38 ` Christian Mayrhuber
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=4149CCB3.1030001@namesys.com \
--to=reiser@namesys.com \
--cc=mjt@nysv.org \
--cc=reiserfs-list@namesys.com \
--cc=will@willsmith.org \
--cc=zam@namesys.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 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.