From: Nix <nix@esperi.org.uk>
To: Ram Ramesh <rramesh2400@gmail.com>
Cc: Drew <drew.kay@gmail.com>, antlists <antlists@youngman.org.uk>,
Linux Raid <linux-raid@vger.kernel.org>
Subject: Re: Best way to add caching to a new raid setup.
Date: Mon, 14 Sep 2020 12:40:31 +0100 [thread overview]
Message-ID: <87v9ggzivk.fsf@esperi.org.uk> (raw)
In-Reply-To: <79c15e0e-5f34-2b1a-282c-8bb36f2e3e81@gmail.com> (Ram Ramesh's message of "Tue, 1 Sep 2020 11:12:40 -0500")
On 1 Sep 2020, Ram Ramesh uttered the following:
> After thinking through this, I really like the idea of simply
> recording programs to SSD and move one file at a time based on some
> aging algorithms of my own. I will move files back and forth as needed
> during overnight hours creating my own caching effect.
I don't really see the benefit here for a mythtv installation in
particular. I/O patterns for large media are extremely non-seeky: even
with multiple live recordings at once, an HDD would easily be able to
keep up since it'd only have to seek a few times per 30s period given
the size of most plausible write caches.
In general, doing the hierarchical storage thing is useful if you have
stuff you will almost never access that you can keep on slower media
(or, in this case, stuff whose access patterns are non-seeky that you
can keep on media with a high seek time). But in this case, that would
be 'all of it'. Even if it weren't, by-hand copying won't deal with the
thing you really need to keep on fast-seek media: metadata. You can't
build your own filesystem with metadata on SSD and data on non-SSD this
way! But both LVM caching and bcache do exactly that.
next prev parent reply other threads:[~2020-09-14 11:43 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <16cee7f2-38d9-13c8-4342-4562be68930b.ref@verizon.net>
2020-08-28 2:31 ` Best way to add caching to a new raid setup R. Ramesh
2020-08-28 3:05 ` Peter Grandi
2020-08-28 3:19 ` Ram Ramesh
2020-08-28 15:26 ` antlists
2020-08-28 17:25 ` Ram Ramesh
2020-08-28 22:12 ` antlists
2020-08-28 22:40 ` Ram Ramesh
2020-08-28 22:59 ` antlists
2020-08-29 3:08 ` R. Ramesh
2020-08-29 5:02 ` Roman Mamedov
2020-08-29 20:48 ` Ram Ramesh
2020-08-29 21:26 ` Roger Heflin
2020-08-30 0:56 ` Ram Ramesh
2020-08-30 15:42 ` Roger Heflin
2020-08-30 17:19 ` Ram Ramesh
2020-09-11 18:39 ` R. Ramesh
2020-09-11 20:37 ` Roger Heflin
2020-09-11 22:41 ` Ram Ramesh
2020-08-29 0:01 ` Roger Heflin
2020-08-29 3:12 ` R. Ramesh
2020-08-29 22:36 ` Drew
2020-09-01 16:12 ` Ram Ramesh
2020-09-01 17:01 ` Kai Stian Olstad
2020-09-02 18:17 ` Ram Ramesh
2020-09-14 11:40 ` Nix [this message]
2020-09-14 14:32 ` Ram Ramesh
2020-09-14 14:48 ` Roger Heflin
2020-09-14 15:08 ` Wols Lists
2020-08-31 19:20 ` Nix
2020-08-28 17:46 ` Roman Mamedov
2020-08-28 20:39 ` Ram Ramesh
2020-08-29 15:34 ` antlists
2020-08-29 15:57 ` Roman Mamedov
2020-08-29 16:26 ` Roger Heflin
2020-08-29 20:45 ` Ram Ramesh
2020-08-30 22:16 ` Michal Soltys
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=87v9ggzivk.fsf@esperi.org.uk \
--to=nix@esperi.org.uk \
--cc=antlists@youngman.org.uk \
--cc=drew.kay@gmail.com \
--cc=linux-raid@vger.kernel.org \
--cc=rramesh2400@gmail.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;
as well as URLs for NNTP newsgroup(s).