From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============6949659938510025024==" MIME-Version: 1.0 From: Artur Paszkiewicz Subject: [SPDK] Re: SPDK RAID5 support Date: Fri, 04 Oct 2019 15:24:37 +0200 Message-ID: <934c24be-3d7a-d462-9e4c-8958f9dd4d74@intel.com> In-Reply-To: 7480C0E9-4A15-4528-A2DC-E0266FF880A3@intel.com List-ID: To: spdk@lists.01.org --===============6949659938510025024== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 c= olor. It would be good I think moving forward to put a trello board up wit= h 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 d= o 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 ref= actoring 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 s= cheme for handling existing RAID0 configured out of band with RAID5 using C= OD. (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 sh= ould 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, n= eeds to be thought out carefully to consider not only extensibility but ver= sion control for backwards compactivity and issues with conflicting COD tha= t are found. For example you have a 3 disk RAID5, take one of the disks ou= t and use it in another array somewhere then bring it back later and fire u= p the original 3, the metadata has to have sufficient info to know who belo= ngs to what and which volumes to create and which to put in some sort of of= fline 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 in= formation it up front. DDF was brought up before in the earlier RAID discus= sions so just to make sure we're all on the same page, I see no value in co= mplying 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 pref= er 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 ma= y 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 RA= ID - like degrade operation and rebuild. Those don't all have to go in at t= he same time however without that minimum set we need to mark it experiment= al, 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 --===============6949659938510025024==--