From: Piergiorgio Sartor <piergiorgio.sartor@nexgo.de>
To: NeilBrown <neilb@suse.de>
Cc: Anshuman Aggarwal <anshuman.aggarwal@gmail.com>,
linux-raid@vger.kernel.org
Subject: Re: Split RAID: Proposal for archival RAID using incremental batch checksum
Date: Mon, 3 Nov 2014 19:04:08 +0100 [thread overview]
Message-ID: <20141103180407.GA3076@lazy.lzy> (raw)
In-Reply-To: <20141103165217.3bfd3d3e@notabene.brown>
On Mon, Nov 03, 2014 at 04:52:17PM +1100, NeilBrown wrote:
[...]
> "simple matter of programming"
> Of course there would be a limit to how much data can be buffered in memory
> before it has to be flushed out.
> If you are mostly storing movies, then they are probably too large to
> buffer. Why not just write them out straight away?
One scenario I can envision is the following.
You've a bunch of HDDs in RAID-5/6, which are
almost always in standby (spin down).
Together, you've 2 SSDs in RAID-10.
All the write (and read, if possible) operations
are done towards the SSDs.
When the SSD RAID is X% full, the RAID-5/6 is
activated and the data *moved* (maybe copied, with
proper cache policy) there.
In case of reading (a large file), the RAID-5/6 is
activated, the file copied to the SSD RAID, and,
when finished, the HDDs put in standby again.
Of course, this is *not* a block device protocol,
it is a filesystem one.
It is the FS that must handle the caching, because
only the FS can know the file size, for example.
bye,
--
piergiorgio
next prev parent reply other threads:[~2014-11-03 18:04 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-29 7:15 Split RAID: Proposal for archival RAID using incremental batch checksum Anshuman Aggarwal
2014-10-29 7:32 ` Roman Mamedov
2014-10-29 8:31 ` Anshuman Aggarwal
2014-10-29 9:05 ` NeilBrown
2014-10-29 9:25 ` Anshuman Aggarwal
2014-10-29 19:27 ` Ethan Wilson
2014-10-30 14:57 ` Anshuman Aggarwal
2014-10-30 17:25 ` Piergiorgio Sartor
2014-10-31 11:05 ` Anshuman Aggarwal
2014-10-31 14:25 ` Matt Garman
2014-11-01 12:55 ` Piergiorgio Sartor
2014-11-06 2:29 ` Anshuman Aggarwal
2014-10-30 15:00 ` Anshuman Aggarwal
2014-11-03 5:52 ` NeilBrown
2014-11-03 18:04 ` Piergiorgio Sartor [this message]
2014-11-06 2:24 ` Anshuman Aggarwal
2014-11-24 7:29 ` Anshuman Aggarwal
2014-11-24 22:50 ` NeilBrown
2014-11-26 6:24 ` Anshuman Aggarwal
2014-12-01 16:00 ` Anshuman Aggarwal
2014-12-01 16:34 ` Anshuman Aggarwal
2014-12-01 21:46 ` NeilBrown
2014-12-02 11:56 ` Anshuman Aggarwal
2014-12-16 16:25 ` Anshuman Aggarwal
2014-12-16 21:49 ` NeilBrown
2014-12-17 6:40 ` Anshuman Aggarwal
2015-01-06 11:40 ` Anshuman Aggarwal
[not found] ` <CAJvUf-BktH_E6jb5d94VuMVEBf_Be4i_8u_kBYU52Df1cu0gmg@mail.gmail.com>
2014-11-01 5:36 ` Anshuman Aggarwal
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=20141103180407.GA3076@lazy.lzy \
--to=piergiorgio.sartor@nexgo.de \
--cc=anshuman.aggarwal@gmail.com \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
/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).