Thanks for taking a look! Yes we can totally limit configurations if nothing else to
simplify both UT and functional test code. I'll probably work on breaking this patch
a bit over the weekend so it's easier to see what's specific to RAID1E or not.
Right now this is sort of a fun science project as it also would need some basic config on
disk to store disk and volume state (at a minimum) over reboots and one could argue that
at least a semi-intelligent rebuild scheme would be needed.
If you've got other ideas please feel free to share!!
On 9/26/19, 8:24 AM, "SPDK on behalf of Liu, Xiaodong"
<spdk-bounces(a)lists.01.org on behalf of xiaodong.liu(a)intel.com> wrote:
Thank you for the quick refreshment on your ongoing RAID enhancement.
Your RAID1E implementation really simplifies the code and its logics.
From my understanding, since all RAID1E situations share a same formula, just with
So just one idea: We can even break up the limitation that number of copies N must be
less than or equal to number of disks M.
Even N > M might be meaningless, or even stupid, but who knows, maybe some user has
that type of weird usage scenario.
How about also supporting N>M, like:
4 disk R1 (5 copeis)
D1 D1 D1 D1
D1 D2 D2 D2
D2 D2 D3 D3
D3 D3 D3 D4
D4 D4 D4 D4
From: SPDK [mailto:firstname.lastname@example.org] On Behalf Of Luse, Paul E
Sent: Sunday, September 22, 2019 11:43 PM
To: Storage Performance Development Kit <spdk(a)lists.01.org>
Subject: [SPDK] RAID1E POC Status
Quick refresher lab, this implantation lays out strips as follow. Dn for Data where n
is the copy number for that strip.
2 disk R1E (1 copy of data, RAID0)
3 disk R1E (2 copies of data)
D1 D1 D2
D2 D3 D3
D4 D4 D5...
3 disk R1 (3 copeis)
D1 D1 D1
D2 D2 D2
D3 D3 D3
So some key points as this patch is just a POC:
* Major benefit is, of course, shared code. Although I added a function table
for RAID related stuff, RAID1E doesn't need it. RAID0 is just a special case of RAID1E
o It also rotates which data copy to read.
* Because of code movement, experiencing a bit this patch is larger than it
needs to be. Just take a look at
o raid0_1e_start_rw_request() which now shares the same completion handler as the
base_bdev focused functions like reset, unmap, etc.
* Some of the non-data payload functions are coded but they're likely
incomplete and full of small bugs as I haven't tested them yet
* r/w have been pretty thoroughly tested (for a POC) w/data integrity testing
Multiple variants of:
o num drives 3,4,5
o num copies 2,3,4
o strip sizes from 512 to 128
o strip size & io_size combo (size < strip, size == strip, size > strip)
o outstanding IO from 1-64
* there's no UT or config stuff (but only one small change is needed for
config), right the RAID1 config is hardcoded so to change recompile
* this can be broken into 4 or 5 patches probably, if we pursue it I will do so
Still just a POC and a lot of work to do before we'd consider production worthy if
we decide to continue with it (I'll work on putting a list together over the next few
Feedback is welcome but please don't review the patch as if it were being
considered for merge, right now it's just a proof of concept to facilitate discussion.
SPDK mailing list
SPDK mailing list