[SPDK] Re: SPDK RAID5 support

[Sasha Kotchubievsky <sashakot at dev.mellanox.co.il>]

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

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 accelerators is possible .
In case of distributed storage, even existing in market network cards can optimize RAID related operations. I believe, the next, upcoming generation will 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: 松本周平 / MATSUMOTO，SHUUHEI <shuhei.matsumoto.xt(a)hitachi.com> 
Sent: Friday, October 4, 2019 1:49 AM
To: Storage Performance Development Kit <spdk(a)lists.01.org>
Cc: Karkra, Kapil <kapil.karkra(a)intel.com>; Baldysiak, Pawel <pawel.baldysiak(a)intel.com>; Ptak, Slawomir <slawomir.ptak(a)intel.com>
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 = 512 + 8, 4096 + 128, or etc) into SPDK RAID?
Do you have any comment?

Thanks,
Shuhei

________________________________
差出人: Luse, Paul E <paul.e.luse(a)intel.com>
送信日時: 2019年10月4日 4:20
宛先: Storage Performance Development Kit <spdk(a)lists.01.org>
CC: Karkra, Kapil <kapil.karkra(a)intel.com>; Baldysiak, Pawel <pawel.baldysiak(a)intel.com>; Ptak, Slawomir <slawomir.ptak(a)intel.com>
件名: [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 color.  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 the backlog and knocking out a large series of small patches to get the refactoring done.

* the current RAID0 has no config on disk. We'll need to come up with a scheme 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, needs to be thought out carefully to consider not only extensibility but version 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 belongs to what and which volumes to create and which to put in some sort of offline state. I don't think we need that kind of capability right up front (deciding how to deal with conflicts) but the metadata should have enough information it up front. DDF was brought up before in the earlier RAID discussions so just to make sure we're all on the same page, I see no value in complying 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 wrt migrations and rebuilds is needed.
* similar to the RAID1E discussions earlier, there are some features you mention 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 backlog includes getting solid UT coverage in there up front.  The existing UT code will likely need some refactoring as well to support the function code refactoring.

-Paul

On 10/3/19, 3:00 AM, "Artur Paszkiewicz" <artur.paszkiewicz(a)intel.com> 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 _______________________________________________
SPDK mailing list -- spdk(a)lists.01.org
To unsubscribe send an email to spdk-leave(a)lists.01.org