All of lore.kernel.org
 help / color / mirror / Atom feed
From: Edward Shishkin <edward@namesys.com>
To: "Xuân Baldauf"
	<xuan--2004.08.01--reiserfs-list--namesys.com@baldauf.org>
Cc: "Vladimir V. Saveliev" <vs@namesys.com>,
	Reiserfs List <reiserfs-list@namesys.com>
Subject: Re: Where to put the journal
Date: Thu, 05 Aug 2004 21:31:33 +0400	[thread overview]
Message-ID: <41126EF5.5080804@namesys.com> (raw)
In-Reply-To: <411268D1.7000101@baldauf.org>

Xuân Baldauf wrote:

> Edward Shishkin wrote:
>
>> Vladimir V. Saveliev wrote:
>>
>>> Hello
>>>
>>> Xuân Baldauf wrote:
>>>
>>>> Hello,
>>>>
>>>> I want to setup a Linux software RAID 5 over disks of different 
>>>> speed with reiserfs on top. I know that the journal has to be 
>>>> accessed frequently for comparably small accesses. That's why I'm 
>>>> considering to "offload" the journal onto an extra partition on a 
>>>> faster disk of the RAID set.
>>>>
>>>> Thus, the journal would not be protected by the RAID, but this is 
>>>> not so important for me.
>>>>
>>>> Is this kind of reasoning sane? Would there be any speedup by 
>>>> offloading the journal?
>>>>
>>>
>>
>> Hello.
>> Unfortunately comprehensive results of journal relocation are obsolete
>> as it was done at the beginning of mongo evolution. As I remember there
>> were no any essential speedups. The only result of  journal  
>> relocation that
>> was created by new mongo benchmark can be found here:
>> http://thebsh.namesys.com/benchmarks/journal_relocation_to_NVRAM.html
>
>
> Thank you,
>
> essentially, these numbers say that relocation provided a speedup of 
> about 10% for write. 


Note this is for data logging journal mode (mount option "data=journal")
Edward.

> This surprises me a bit, because I expected a significantly smaller 
> seek count for a write operation. Nevertheless, maybe I should run 
> benchmarks with many small files for myself. :-)
>
>>
>> Edward.
>
>
>
> ciao,
>
> Xuân Baldauf.
>
>>
>>> Person who did some tests on non standard journal is on vacation. He 
>>> is expected to come back today. Maybe he remembers benchmark results,
>>
>>
>
>
>


      reply	other threads:[~2004-08-05 17:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-01 11:11 Where to put the journal Xuân Baldauf
2004-08-02  9:27 ` Vladimir V. Saveliev
2004-08-05 16:39   ` Edward Shishkin
2004-08-05 17:05     ` Xuân Baldauf
2004-08-05 17:31       ` Edward Shishkin [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=41126EF5.5080804@namesys.com \
    --to=edward@namesys.com \
    --cc=reiserfs-list@namesys.com \
    --cc=vs@namesys.com \
    --cc=xuan--2004.08.01--reiserfs-list--namesys.com@baldauf.org \
    /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.