From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============2411475545200372020==" MIME-Version: 1.0 From: David Butterfield Subject: [SPDK] Re: SPDK RAID5 support Date: Thu, 03 Oct 2019 09:55:46 -0600 Message-ID: <45cb5a6c-4b18-f3ab-939b-6cc5339d9c7c@gmail.com> In-Reply-To: 3b5a046b-953f-d45c-f5aa-4191222b3bbe@intel.com List-ID: To: spdk@lists.01.org --===============2411475545200372020== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable I have DRBD 9.0 running in usermode under SPDK as shown in this diagram: https://raw.githubusercontent.com/DavidButterfield/spdk/tcmu-runner/spd= k_drbd.pdf One possibility would be to port a kernel RAID module into the spot occupie= d by DRBD in the diagram. The "port" of DRBD to run in usermode changes fewer than a dozen lines of c= ode from the original source in the LINBIT repository. Rather than changin= g 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 use= rmode 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 s= ame to be possible for a kernel RAID module. It won't just "drop in", beca= use the set of emulated kernel functions has to be expanded to include what= ever 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-ti= me 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 R= AID > projects, primarily with Linux MD RAID, which we actively develop and sup= port > for Intel VROC. We already have an initial SPDK RAID5 implementation crea= ted > for an internal project. It has working read/write, including partial-str= ipe > 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 RAI= D0 > 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 >=20 --===============2411475545200372020==--