From: Timofey Titovets <nefelim4ag@gmail.com>
To: linux-mm@kvack.org
Subject: Fwd: Why rapiddisk cache, better then build-in ram cache?
Date: Thu, 11 Jun 2015 18:47:50 +0300 [thread overview]
Message-ID: <CAGqmi74GXnXND85DUAHnTefMs0ed=qM7ZndMmZxVpP7t6qExvQ@mail.gmail.com> (raw)
In-Reply-To: <CA+KgHt_4rnCdh-_PUJNOpkQZAse5EWn9cDxBhfbJzKR_C=-K3A@mail.gmail.com>
Hello list,
I'm very sorry, what i've forward mail it to linux-mm list, but i
can't find any mailing list like linux-block-io or something like that
%)
I've recently find rapid cache and it confuse me, as i know, linux use
almost all free ram for IO caching and do it very cool and fast.
May be i misstake in something? May be linux memory io cache sub
system not fast as i think?
---------- Forwarded message ----------
From: Petros Koutoupis <pkoutoupis@inverness-data.com>
Date: 2015-06-11 18:33 GMT+03:00
Subject: Re: Why rapiddisk cache, better then build-in ram cache?
To: Timofey Titovets <nefelim4ag@gmail.com>
Копия: support@inverness-data.com
Timofey,
Thank you very much for you interest in the project.
Linux does not have a built block I/O cache. All block I/O resides in
a temporary buffer until the schedular schedules the task to the block
device; that is, unless you are running Direct I/O in which all I/O is
immediately dispatched regardless of the schedular. Now a file system
will cache data in the VFS layer but this cache is somewhat small and
limited. With RapidDisk / RapidCache, you can easily enable 1GB or
even 1TB of cache to a slower block device, thus enabling a block
based cache. Or you can simply just enable a large RAM based block
device and not use it as a cache. I guess it all depends on your
requirements.
You are correct, though. This should be detailed on the Wiki and I
will definitely address it. Thank you for bringing it to our
attention.
On Thu, Jun 11, 2015 at 10:26 AM, Timofey Titovets <nefelim4ag@gmail.com> wrote:
>
> Hello,
> i've read http://rapiddisk.org/index.php?title=Main_Page
> That a very cool,
> but i can't understand why it better than linux built in file/block io cache?
>
> May be you can explain it on wiki page?
>
> --
> Have a nice day,
> Timofey.
--
Petros Koutoupis
Inverness Storage Solutions, LLC
312-854-9707
pkoutoupis@inverness-data.com
--
Have a nice day,
Timofey.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
parent reply other threads:[~2015-06-11 15:48 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <CA+KgHt_4rnCdh-_PUJNOpkQZAse5EWn9cDxBhfbJzKR_C=-K3A@mail.gmail.com>]
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='CAGqmi74GXnXND85DUAHnTefMs0ed=qM7ZndMmZxVpP7t6qExvQ@mail.gmail.com' \
--to=nefelim4ag@gmail.com \
--cc=linux-mm@kvack.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox