From: Manuel Krause <manuelkrause@netscape.net>
To: Chris Mason <mason@suse.com>
Cc: reiserfs-list <reiserfs-list@namesys.com>
Subject: Re: udpated data logging available
Date: Thu, 26 Jun 2003 15:36:23 +0200 [thread overview]
Message-ID: <3EFAF6D7.9040408@netscape.net> (raw)
In-Reply-To: 1056632026.20899.39.camel@tiny.suse.com
On 06/26/2003 02:53 PM, Chris Mason wrote:
> On Thu, 2003-06-26 at 07:42, Dieter Nützel wrote:
>
>>>Great to hear, thanks for giving it a try. io-stalls-6 helped most when
>>>you've got multiple devices and a streaming write to one was slowing
>>>down all the others. -7 added in a tweaked form of Andrea's elevator
>>>latency fixes, and they make a big difference when there's a lot of
>>>writes to the drive you're trying to read from.
>>
>>So, does it apply to 2.4.21-aa1 (latest is 2.4.21rc8aa1) cleanly? ;-)
>>
>
> No, io-stalls-7 is mostly in rc8aa1 already. The major difference is
> that andrea changed blk_finished_io and I added a new func to keep
> compatibility for external drivers. There are a few areas where he and
> I chose different ways of doing things, if you're interested in helping
> add some measurements to our debate, I can make you a patch against aa1.
>
>>>Hopefully we'll be able to hash out something suitable for 2.4.22-pre.
>>
>>2.4.22-pre1 is out form some days...
>
> Yes. Almost all my latency testing was done on data logging + the jh-2
> patch, so I'm much more confident now in that code. Hopefully the
> merging will start shortly, Oleg has a queue of things he wants to get
> in, and we're trying to keep the rate of changes at something
> manageable.
>
> (quick clarification, io-stalls-7 is entirely unrelated to reiserfs, I
> posted it here because I thought there might be some willing testers ;-)
>
> -chris
Hi,
the complete data-logging patchset including the experimental ones is
running fine on here, kernel 2.4.21-final without quota, with
rml-preempt-kernel and with the "old" search_reada-4. It also ran fine
with the previous reiserfs-jh-1 and io-stalls-6 before.
Does the search_reada-4 contradict the new code or is it even dangerous
to combine them (what I luckily didn't trigger so far)?
Thanks,
Manuel
next prev parent reply other threads:[~2003-06-26 13:36 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-16 11:47 udpated data logging available Chris Mason
2003-06-18 13:56 ` Chris Mason
2003-06-23 2:45 ` Chris Mason
2003-06-23 16:53 ` Christian Mayrhuber
2003-06-25 19:15 ` Chris Mason
2003-06-26 0:16 ` Christian Mayrhuber
2003-06-26 1:47 ` Chris Mason
2003-06-26 11:42 ` Dieter Nützel
2003-06-26 12:53 ` Chris Mason
2003-06-26 13:36 ` Manuel Krause [this message]
2003-07-01 23:41 ` Manuel Krause
2003-07-02 1:44 ` Chris Mason
2003-06-26 17:19 ` Dieter Nützel
2003-07-02 0:46 ` Manuel Krause
2003-07-02 1:46 ` Chris Mason
2003-06-26 11:48 ` Dieter Nützel
2003-06-26 12:18 ` Philippe Gramoullé
2003-06-26 12:35 ` Dieter Nützel
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=3EFAF6D7.9040408@netscape.net \
--to=manuelkrause@netscape.net \
--cc=mason@suse.com \
--cc=reiserfs-list@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.