From mboxrd@z Thu Jan  1 00:00:00 1970
Content-Type: multipart/mixed; boundary="===============9099756509752356239=="
MIME-Version: 1.0
From: Walker, Benjamin <benjamin.walker at intel.com>
Subject: Re: [SPDK] Basic design of linear bdev (aggregating multi bdevs)
Date: Thu, 13 Sep 2018 17:05:58 +0000
Message-ID: <896776e8ee5d46fa5ca0d962bec7a7f4d104c951.camel@intel.com>
In-Reply-To: OS1PR01MB0229C947D5952A0FA14B4A4EA21A0@OS1PR01MB0229.jpnprd01.prod.outlook.com
List-ID: <spdk@lists.01.org>
To: spdk@lists.01.org

--===============9099756509752356239==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

On Thu, 2018-09-13 at 02:46 +0000, =E6=9D=BE=E6=9C=AC=E5=91=A8=E5=B9=B3 / M=
ATSUMOTO=EF=BC=8CSHUUHEI wrote:
> Hi All,
> =

> =

> As I talked shortly in the community before, I'm working on linear bdev
> (aggregating mutilple bdevs) as part of my works.

Just to clarify a bit more - this bdev concatenates bdevs, placing one afte=
r the
other, right? Are you able to share use cases for this type of volume? My
primary concern is that higher layers in the software stack often are desig=
ned
to prefer to write to lower LBAs, so concatenation results in hammering the
first disk and hardly touching the rest. Often, a RAID 0 with very large st=
rips
(1MB) ends up working better. There are other considerations, such as what
happens when a disk fails, that may make RAID 0 infeasible, but it's someth=
ing
to consider.

> =

> =

> The following is my present basic design of the linear bdev.
> =

> =

> Linear bdev doesn't belong to raid but I want to add linear bdev as anoth=
er
> level of raid bdev.
> =

> Raid bdev and IO splitting in bdev will be able to become the great
> foundation.

For a bdev that is made as a concatenation of other bdevs there won't be mu=
ch
splitting necessary and I think the algorithm is unique enough that you cou=
ld do
something specific to the concatentation code instead of relying on generic
splitting in the bdev layer. I think that's a simpler approach overall.

> =

> =

> bdev:
> -  Utilize current IO splitting as much as possible.
> -  In linear bdev, optimal_io_boundary is not constant and linear bdev ca=
n't
> use current implementation based on optimal_io_boundary.
> =

> -  Add an array made of (start, length) pair to struct spdk_bdev instead =
of
> optimal_io_boundary.
> -  Abstract the following APIs:
>   - bool _spdk_bdev_io_should_split(struct spdk_bdev_io *bdev_io)
>   - uint32_t _to_next_boundary(uint64_t offset, uint32_t boundary)
> - The (start, length) array and optimal_io_boundary are mutually exclusiv=
e.
> =

> =

> raid_bdev:
> - Utilize current implementation as much as possible.
> - Abstract the following:
>  - raid_bdev_configure()
>    - check consistency among base bdevs, calculate total block counts, add
> split info to spdk_bdev
>  - raid_bdev_start_rw_request() and following functions
> - Use -1 as the level of the linear bdev.
> =

> =

> rpc:
> - Add an new parameter linear (bool) to construct_raid_bdev.
> - raid_level and linear are mutually exclusive.
> =

> =

> Your any feedback is very welcome.
> =

> =

> Thanks,
> =

> Shuhei
> _______________________________________________
> SPDK mailing list
> SPDK(a)lists.01.org
> https://lists.01.org/mailman/listinfo/spdk


--===============9099756509752356239==--