From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============1796355217229483593==" MIME-Version: 1.0 From: Sasha Kotchubievsky Subject: [SPDK] Re: SPDK RAID5 support Date: Sun, 13 Oct 2019 12:26:28 +0300 Message-ID: <004701d581a8$4b613bd0$e223b370$@dev.mellanox.co.il> In-Reply-To: TYAPR01MB29891FEE6898F2AC3C7E9D89A29F0@TYAPR01MB2989.jpnprd01.prod.outlook.com List-ID: To: spdk@lists.01.org --===============1796355217229483593== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi, I'm very exiting to progress in RAID development in SPDK. Artur, will you focus on RAID5 only, or RAID6 is also will be supported? I think, it's important to keep existing SPDK approach for configuration. = It would nice to see an abstraction for parity calculation. I believe, the = calculation can be optimized for specific platform, or even using HW accele= rators is possible . In case of distributed storage, even existing in market network cards can o= ptimize RAID related operations. I believe, the next, upcoming generation w= ill this capabilities to the next level. That needs some support from bdev = layer like events about configuration changes, or recovery/degradation. Best regards Sasha -----Original Message----- From: =E6=9D=BE=E6=9C=AC=E5=91=A8=E5=B9=B3 / MATSUMOTO=EF=BC=8CSHUUHEI = Sent: Friday, October 4, 2019 1:49 AM To: Storage Performance Development Kit Cc: Karkra, Kapil ; Baldysiak, Pawel ; Ptak, Slawomir Subject: [SPDK] Re: SPDK RAID5 support Hi Artur, Paul, and All, Thank you so much, I'm excited to know this. Recently SPDK are starting to support DIF feature. Can we have any possibility to include the extended LBA (block size =3D 512= + 8, 4096 + 128, or etc) into SPDK RAID? Do you have any comment? Thanks, Shuhei ________________________________ =E5=B7=AE=E5=87=BA=E4=BA=BA: Luse, Paul E =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: 2019=E5=B9=B410=E6=9C=884=E6=97=A5 4:= 20 =E5=AE=9B=E5=85=88: Storage Performance Development Kit CC: Karkra, Kapil ; Baldysiak, Pawel ; Ptak, Slawomir =E4=BB=B6=E5=90=8D: [SPDK] Re: SPDK RAID5 support Hi Artur, Thanks, I think this can be an awesome contribution. A few other things to= consider, you mention some of these already, so I just added some more col= or. It would be good I think moving forward to put a trello board up with = a backlog of tasks so that others (like me __) can jump in and help also. = I'd still like to get the RAID1E in there, but it makes little sense to do = it before any major refactoring. I think it makes sense, if you guys are ready, to start putting together th= e backlog and knocking out a large series of small patches to get the refac= toring done. * the current RAID0 has no config on disk. We'll need to come up with a sch= eme for handling existing RAID0 configured out of band with RAID5 using COD= . (like not allowing a RAID0 to be built on a set with COD, etc.) * the metadata layout, as you knee from working previous RAID projects, nee= ds to be thought out carefully to consider not only extensibility but versi= on control for backwards compactivity and issues with conflicting COD that = are found. For example you have a 3 disk RAID5, take one of the disks out = and use it in another array somewhere then bring it back later and fire up = the original 3, the metadata has to have sufficient info to know who belong= s to what and which volumes to create and which to put in some sort of offl= ine state. I don't think we need that kind of capability right up front (de= ciding how to deal with conflicts) but the metadata should have enough info= rmation it up front. DDF was brought up before in the earlier RAID discussi= ons so just to make sure we're all on the same page, I see no value in comp= lying with that spec. Open to other thoughts though. * one thing to keep in mind, we probably want to retain common RPC code * we should keep migration in mind as well, not that it's something we may = ever need/want but lots of reserved space in metadata for tracking state wr= t migrations and rebuilds is needed. * similar to the RAID1E discussions earlier, there are some features you me= ntion as 'future' that most would consider a requirement for redundant RAID= - like degrade operation and rebuild. Those don't all have to go in at the= same time however without that minimum set we need to mark it experimental= , so nobody tries to use it thinking it has those basic things. * I can't remember if we talked about unit tests or not, but be sure the ba= cklog includes getting solid UT coverage in there up front. The existing U= T code will likely need some refactoring as well to support the function co= de refactoring. -Paul =EF=BB=BFOn 10/3/19, 3:00 AM, "Artur Paszkiewicz" wrote: Hi all, We want to add RAID5 support to SPDK. My team has experience with other= RAID projects, primarily with Linux MD RAID, which we actively develop and s= upport for Intel VROC. We already have an initial SPDK RAID5 implementation cr= eated for an internal project. It has working read/write, including partial-s= tripe updates, parity calculation and reconstruct-reads. Currently in SPDK there exists a RAID bdev module, which has only RAID0 functionality. This can be used as a basis for a more generic RAID stac= k. Here is our idea how to approach this: 1. Refactor the bdev_raid module to separate RAID0-specific I/O handlin= g code from more generic parts - configuration, bdev creation, etc. Move the R= AID0 code to a new file. Use RAID level-specific callbacks, similar to exist= ing struct raid_fn_table. This architecture is also used in MD RAID drivers= , where different RAID "personalities" work on top of a common layer. 2. Add RAID5 support in another file, similarly to RAID0. Port our curr= ent RAID5 code to this new framework. 3. Incrementally add new functionalities. At this point, probably the m= ost important will be support for member drive failure and degraded operati= on, RAID rebuild and some form of on-disk metadata. Any comments or suggestions are welcome. Thanks, Artur _______________________________________________ SPDK mailing list -- spdk(a)lists.01.org To unsubscribe send an email to spdk-leave(a)lists.01.org _______________________________________________ SPDK mailing list -- spdk(a)lists.01.org To unsubscribe send an email to spdk-leave(a)lists.01.org _________________= ______________________________ SPDK mailing list -- spdk(a)lists.01.org To unsubscribe send an email to spdk-leave(a)lists.01.org --===============1796355217229483593==--