[SPDK] Re: SPDK RAID5 support

[Artur Paszkiewicz <artur.paszkiewicz at intel.com>]

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

On 10/3/19 9:20 PM, Luse, Paul E wrote:
> 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.

I'll start working on the backlog and refactoring in the upcoming weeks.

> * 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.)

Good point. My initial thought is that any bdev containing RAID metadata should
be claimed by the module as soon as it is discovered (module's examine
handler?).

> * 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.

Using DDF would have big benefits, we wouldn't have to re-invent the wheel and
would be able to use the RAID arrays in other environments, with existing
tools, etc. I think we can consider adding support for this at some point. For
now, something less complex should be OK. We can use mdraid native metadata as
reference. It is simple and works well for stackable block device software raid,
similar to what we are going to be building. It has its quirks, so I'd prefer
not using the same exact format.

> * one thing to keep in mind, we probably want to retain common RPC code

I agree.

> * 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.

For rebuild a simple checkpoint should be sufficient. Migration can require a
backup area, but maybe we don't have to reserve space for that on the data
drives? Let's say that a migration process will require providing separate
storage for the backup.

> * 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.

By 'future' I meant not included in the initial patchset. Of course, those
things will have to be included if this to be considered stable.

> * 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.

Yes, I assumed this will be necessary.

Thanks,
Artur