[SPDK] Re: SPDK RAID5 support

[Luse, Paul E <paul.e.luse at intel.com>]

[-- Attachment #1: Type: text/plain, Size: 4111 bytes --]

Hi David,

Thanks for reminding me that you had similar feedback that I don't think I replied to wrt RAID1E as I just got distracted by another shiny thing (

We talked about a few things wrt the recent RAID discussions in the last community meeting. In general, the primary driver behind choosing a path is architectural fit within SPDK. Then there's the implementation details that must take into account that we already have a RAID0 module in tree. So although we want to consider every option, any kind of port or drop in is unlikely to be a good fit for SPDK but we're not done talking about this stuff either... after some more email discussion on Artur's note, we'll likely put it on the agenda again for the next community meeting.  Would be great if you can keep an eye out and join us. https://spdk.io/community/ 

Artur, I'll reply to your email separately a bit later on today.

Thanks!
Paul

On 10/3/19, 8:56 AM, "David Butterfield" <dab21774(a)gmail.com> wrote:

    I have DRBD 9.0 running in usermode under SPDK as shown in this diagram:
    
        https://raw.githubusercontent.com/DavidButterfield/spdk/tcmu-runner/spdk_drbd.pdf
    
    One possibility would be to port a kernel RAID module into the spot occupied by DRBD in the diagram.
    
    The "port" of DRBD to run in usermode changes fewer than a dozen lines of code from the original source in the LINBIT repository.  Rather than changing the source code from the DRBD kernel module, its expected environment is simulated around it.  (This is intended to make it easier to update the usermode port to newer versions of the application as they appear.)
    
    I did the same thing with SCST a couple of years ago.  I would expect the same to be possible for a kernel RAID module.  It won't just "drop in", because the set of emulated kernel functions has to be expanded to include whatever the RAID module uses that isn't already covered by the existing ports of SCST and DRBD.  I estimate it would take me one to two months of full-time work to get a kernel RAID module up and running well enough to be tested and used for experimentation.
    
    Regards,
    David Butterfield
    -----------------
    
    On 10/3/19 3:59 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 support
    > for Intel VROC. We already have an initial SPDK RAID5 implementation created
    > for an internal project. It has working read/write, including partial-stripe
    > 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 stack. Here
    > is our idea how to approach this:
    > 
    > 1. Refactor the bdev_raid module to separate RAID0-specific I/O handling code
    > from more generic parts - configuration, bdev creation, etc. Move the RAID0
    > code to a new file. Use RAID level-specific callbacks, similar to existing
    > 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 current
    > RAID5 code to this new framework.
    > 
    > 3. Incrementally add new functionalities. At this point, probably the most
    > important will be support for member drive failure and degraded operation, 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